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Introduction 


were: 


Th,s  publication  contain  copies  ot  the  materia]  presented  at  the  NASA  Formal  Methods 

»■ The  «°ds  °f  ihe  w°ikshop 

Introduce  the  formal  methods  research  teams  to  a broader  view  of  the  aerospace  prob- 
lem  domain  by  industry  presentations. 

• Drtailed  technical  exchange  between  formal  methods  research  teams  to  define  and 
"erize  the  verification  problem  for  ultra-reliable  life-critical  flight  control  systems. 

. Identification  of  aerospace  problems  which  can  benefit  from  formal  methods  and  can 
serve  as  the  basis  of  future  research  efforts. 

The  NASA  effort  in  formal  methods  includes  researchers  at  NASA  LaRC,  Computational 
LoJc  Jnc  Odyssey  Research  Associates,  SRI  International,  Boeing  Military,  Vigyan  and 
the  University  of  California  at  Davis  and  Irvine.  Also  NASA  Langley  is  invo  ve  in  * J™n 
research  effort  with  the  UK  Royal  Signals  and  Radar  Establishment  as  formalized  in 

Memorandum  of  Understanding  between  the  two  organisations. 

Attendees  at  the  workshop  included  NASA  personnel,  researchers  from  the  four  sup 

RQRF  Dersonnel  invited  speakers,  and  representatives  from 
porting  contract  organizations,  RbKk  personnel,  invite  y A+^ndance  was 

other  government  research  organizations  with  interests  in  formal  methods.  Attendance 
by  invitation  only. 
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Day  1 


NASA  Formal  Methods  Workshop  Agenda 
(Aug  20-23,  1990) 


8:00  - 8:20  am 
8:20  - 8:30  am 
8:30  - 8:45  am 
8:45  - 9:30  am 

Milt.  Holt 
Ricky  W.  Butler 
Chuck  Meissner 

Late  Registration 
Greeting  by  Chief  of  ISD 
Workshop  Objectives 
Digital  Avionics:  A Cornerstone 
of  Aviation 

9:30  - 10:15  am 

James  McWha 

Life  Critical  Digital 

Flight  Control  Systems  (DFCS) 

10:15  - 10:30  am 

BREAK 

10:30  - 11:30  am 

Jerry  Cohen 

Advanced  Embedded  Processing: 
Present  and  Future 

11:30  - 12:30  am 

LUNCH 

12:30  - 1:30  pm 
1:30  - 2:00  pm 

Roger 
Kieckhafer 
Rick  Butler 

MAFT:  The  Multicomputer  Architect 
for  Fault  Tolerance 
Design  For  Validation 

2:00  - 2:30  pm 

BREAK 

2:30  - 3:00  pm 
3:00  - 3:30  pm 
3:30  - 4:00  pm 

Richard  Platek 
John  Rusliby 
Don  Good 

What  FM  can  offer  to  DFCS  design 
What  FM  can  offer  to  DFCS  design 
What  FM  can  offer  to  DFCS  design 

7:00  pm 

Conference  Dinner 

Day  2 


OS  verification 


8:30  - 9:30  am 
9:30  - 10:15  am 
10:15  - 10:30  am 

10:30  - 11:30  pm 

11:30  - 12:30  am 
12:30  - 1:30  am 

1:30  - 2:00  pm 
2:00  - 2:30  pm 

2:30  - 3:00  pm 

3:00  - 4:00  pm 
4:00  - 4:30  pm 


DiVito 

Rushby 


High  Level  Design  Proof 

of  a Reliable  Computing  Platform 

A Verified  Model  of  Fault  Tolerance 


BREAK 


Byzantine  Generals 


Bevier  & Young  The  Design  and  Verification  of 

a Fault-tolerant  Circuit 


LUNCH 

Srivas 


Hunt 

Windley 


Verifying  an  Interactive 
Consistency  Circuit 

— Microprocessor 


Hardware  Verification  at, 
Computational  Logic  Inc. 
Generic  Interpreters  and 
Microprocessor  Verification 


BREAK 

Pygott/Kershaw  VIPER  2 t NODEN 
Discussion 


Day  3 


8.30  - 10:00  am 

Shankar/Rushby 

10:00  - 10:30  am 

Discussion 

10:30  - 11:30  pm 

Levitt 

11:30  - 12:00  pm 

Caldwell/ Carreno  / 
Miner 

12:00-  1:00  pm 

lunch 

Clock  Synchronization  — 

Mechanical  Proofs  of  Fault- 
Tolerant  Clock  Synchronization 

— Commercial  Chips 

Floating.pt.  Coprocessor  (Intel  8087 
MA  controller  (Intel  8237A)  etc 
(Not  in  Proceedings) 

An  HOL  Theory  For  Voting 


1:00  - 1:45  pm 

Guaspari 

1 -45  - 2:30  pm 

Hoover 

2:30  - 3:00  pm 

Hoover 

3:00  - 3:30  pm 

break 

3:30  - 5:00  pm 

Planning 

Day  4 

8:30  - 12:00  pm 

Discussion 

Formally  Specifying  the  Logic  Of 
Utomatic  Guidance  Control  (Ada, 
Verification  of  Floating-point 
Software 


C Formal  Verification  with  Unix 
Communication  and  Concurrency 


Bill  Bevier 
Deepak  Kapur 
Dale  Johnson 
Andy  Moore 
Karl  Levitt 
Sally  Johnson 
Richard  Platek 
Bill  Young 
Don  Good 
Warren  Hunt. 

Jim  Caldwell 
Mark  Bickford 
Mark  Saaltink 
Bill  Legato 
Kang  Shin 
Chuck  Meissner 
Pete  Saraceni 
Roger  Kieckhafer 
Doug  Hoover 
David  Gnaspari 
Toni  Schuhcrt. 
Mark  Ardis 
Clive  Pygott 
John  Kershaw 
David  Musser 
Phil  Wind  ley 
John  Knight 
Rick  Kuhn 
Dave  Eckhardt 
John  McHugh 
Milt  Holt 
Ben  DiVito 
Paul  Miner 
Rick  Butler 

M. K.  Srivas 
John  Rushby 

N.  Shankar 
Gerry  Cohen 


NASA  FM  Workshop  Attendees 


CLl 

SUNY,  Albany 

MITRE(Bedford) 

NRL 

DC  Davis 

NASA,  LaRC 

ORA 

CLl 

CLl 

CLl 

NASA 

ORA 

ORA 

NSA 

11.  Michigan 
NASA,  LaRC 
FA  A Tech  Ctr. 

XT.  Nebraska 

ORA 

ORA 

UC  Davis 

SEI 

RSRE,  Malvern 
RSRE,  Malvern 
RPI 

U. Idaho 
U.  Va. 

NIST 

NASA,  LaRC 
CLl 

NASA,  LaRC 

Vigyan/N  ASA 

NASA,  LaRC 

NASA,  LaRC 

ORA 

SRI 

SRI 

Boeing 


(512)322-9951 
(518)442-4281 
(617)271-8894 
(202)767-6698 
(916)752-0832 
(804)864-6204 
(607)277-2020 
(512)322-9951 
(512)322-9951 
(512)322-9951 
(804)864-6214 
(607)277-2020 
(613)238-7900 
(301)688-4229 
(313)703-0391 
(804)864-6218 
(609)484-5577 
(402)472-2402 
(607)277-2020 
(607)277-2020 
(916)752-6452 
(412)268-7636 
44-684-895835 
44-684-895845 
(518)276-8660 
(208)885-6501 
(804)982-2216 
(301)975-3337 
(804)864-1698 
(919)493-4932 
(804)864-1596 
(804)864-4883 
(804)864-6201 
(804)864-6198 
(607)277-2020 
(415)859-5456 


bevier@cli.com 

kapur@albanycs.albany.edu 


??? 


(206)865-3739 


moore@itd.nrl.navy.mil 

levitt@ucdavis.edu 

sci@airl6.larc.nasa.gov 

richard%oravax.uucp@cu-arpa.cs.cornell.edu 

y oung@  cli.  com 

good@cli.com 

???  %oravax .uucp @ cu-arpa.es .corne 
maxk@ora.on.ca 

kgshin@eecs  .umich.edu 

cwm@airl2.larc.nasa.gov 
rogerk@fergvax.unl.edu 

hoove  %oravax  .uu  cp@  cu-  arp  a.  cs . corne  - 

???  %oravax.uucp@cu-arpa.cs. comell.edu 

schubert  ® iris  .uedavis  .edu 

”RyG01^T%hermeS.mod.\ik,'@relay.MOD.UK^ 

"KERSHAW%hermes.mod.uk"  ©relay. 
musser@tuxing.cs.rpi.edu 
windley@ted.mrc.uidaho.edu 
jck@neptune.cs.virginia.edu 

dee@csab.larc.nasa.gov 

mchugh@cli.com 
bld@turl6.larc.nasa.gov 

psm@airl6.laxc.nasa.gov 
rwb@Mrl6.laxc.nasa.gov 

s,i,as%o»v^.aUcp®cu«ip».cs.cornell.e<lU 

rushby@csl.sri.com 
shankar@csl.sri.com 
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TO  CROSS  CHECK  SIMULATION  RESULTS  - 
AUTOLAND  SYSTEM  COULD  REQUIRE  200-300 
LANDINGS  OVER  AN  8 MONTH  PERIOD 
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Abstract 


This  presentation  discusses  several  design loosely 

flight -critical  real-time  applications.  objectives  and  architec- 

The  presentation  begins  with  an  overview  of  the  MAH  6 f • maFT 

^s=rs£ar.tr!iii=s=r£= 

Scheduling  and  Error  Handling  subsystems. 
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Presentation  Overview 

• INTRODUCTION 

• SYSTEM  FUNCTIONS 

- Communication 

- Task  Scheduling 
Task  Reconfiguration 

- Clock  Synchronization 
Data  Handling  and  Voting 
Error  Handling  and  Recovery 

• SUMMARY 
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Design  Objectives 


• RELIABILITY  - 1.0  X 10  9 over  10  hours. 


• performance 


200  Hz.  - Max  Task  Iteration  Rate 

5 5 MIPS  - Max  Computational  Capacity 

10  MBPS  - Max  I/O  Transfer  Rate 
no  1 - Min  Transport  Lag  (Input  - 


Output) 


• REUSABLE 

- Functional  Partitioning 

• Application  Specific  Functions 

• Standard  Executive  Functions 


• LOW  EXECUTIVE  OVERHEAD 

- Physical  Partitioning 

. Separate  Executive  Processor 
• Hardware  Intensive 


NASA  FM  W-S1IOP 
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Loosely-Coupled  Multiprocessor 


OUTPUT  DEV 


• Node  =>  Processor  and  Private  Memory 

• No  Shared  Memory 


• Message-Based  Inter-Node  Communication 

• Common  Operating  System 


srf' 


I 


1 MAFT  System  Architecture 


SYSTEM 

OVERHEAD: 

- COMMUNICATION 

- TASK  SCHEDULING 

- RECONFIGURATION 

- DATA  VOTING 

- ERROR  DETECTION 

- SYNCHRONIZATION 


V 


4 


APPLICATION 

PROGRAMS 


• OC  Operations  Controller. 

Special  Purpose  Device  Common  to  All  MAFT  System: 


• AP  =>  Application  Processor. 

General  Purpose  Application-Specific  Processor. 


UNL/CSE/RMK/Augu»t  15,  1990 
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Operations  Controller  Block  Diagram 


application 

PROCESSOR 


UNL/CSE/RMK/Augu»t  16,  1990 
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COMMUNICATION 


UNL/CSE/RMK/Au*u*tl«,  1M» 


CS-I 


INTER-PROCESSOR  communications 


I/O  DEV 


- INTRA-NETWORK  COMMUNICATION 

MESSAGES  TRANSMITTED  ON  PRIVATE  SERIAL  BROADCAST  BUSSES 

- all  WOES  RECEIVE,  CHECK  AND  PROCESS  ALL  MESSAGES 

- MESSAGE  TYPES 

DATA  (8/16/32B  I NT  OR  BOOL/  IEEE  STD  32b  FLOAT) 

TASK  COMPLETED  / STARTED  / BRANCH 

SYNCHRONIZATION  / BRANCH  INTERACTIVE  CONSISTENCY 
- ERROR  REPORT 

- oc  / AP  COMMUNICATION 

16  BIT  ASYNCHRONOUS  P. I.O.  INTERFACE 
LOOKS  LIKE  "JUST  ANOTHER  I/O  PORT"  TO  AP 
COMPATIBLE  W EXISTING  UNIPROCESSOR  OPER  SYST 


February  28/  1986 


Message  Handling 


• TRANSMITTER 

- Format  Msg  - NID,  Msg  Type,  Framing,  ECC 

- Broad'  ?''*  Msg 

• RECEIVER':)  1 per  incoming  link 

_ Accent  1 n'perly  Framed  Bytes 

- Buffer  Bv.e  for  Message  Checker 

• MESSAGE  CHECKER 

- Poll  R<  ' ; 'ers  - 6.4  /xs  cycle 

- Phys;  ■ nd  Logical  Checks 

- Steer  ' ujod  Messages  to  Other  Subsystems 

- Dump  Bad  Messages  into  “Bit-Bucket 
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LOCAL  AP/OC  INTERFACE  OPERATIONS 


1 . TASK  SWITCHING  PROCESS 

- AP:  DONE  WITH  LAST  TASK,  WHAT  IS  THE  TASK  IDENTIFICATION  (TID) 

NUMBER  OF  THE  NEXT  TASK. 

- OC:  HERE  IT  IS 

2.  TRANSFER  DATA  FROM  OC  TO  AP 

- AP:  GIVE  ME  THE  NEXT  INPUT  DATA  VALUE 

- OC:  HERE  IT  IS 

3.  TRANSFER  DATA  FROM  AP  TO  OC 

- AP:  HERE’S  THE  NEXT  OUTPUT  DATA  VALUE 

- OC:  I GOT  IT 


+ ATC/RMK  February  28,  1986 


Typical  Task  System 


UNL/CSE/RMK/AugumilS. 
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PERFORMANCE  ISSUES 


• STRICTLY  PERIODIC  SCHEDULER 

- Fast  - Freq  Well  Above  Spec  - 500  Hz.  vs.  200  Hz 

- Simple  - Binary  Freq  Dist  (/_•  = 2 -*'/„) 

- Flexible  - Conditional  Branching 

- Efficient  - Don’t  Keep  AP  Waiting 

• NON-PREEMPTIVE 

- Scheduler  Complexity 

- Context  Switching  Time  - Unknown  Funct  of  AP 

- High  Frequencies  - Short  Tasks 


• NO  OC  INTERRUPTS  - I/O 

Scheduler  Complexity 

- Predictability 

- High  Frequencies  - Polling 

- DMA  or  IOP  access  to  AP  Memory 


UNL/CSE/RMK/Dceemb«r  29,  19SS 


O.c.  View  of  a Task 


. INTERNAL  FUNCTION  IS  BLACK  BOX 

• VISIBLE  PROPERTIES  OF  A TASK 

- Priority  (static,  unique) 

- Iteration  Period 

- Precedence  Constraints 

. Min  and  Max  duration  Limits 

- Fixed  Input  and  Output  Shared  Data  Sets 

- Branch  Condition  (asserted  at  completion) 


UNl</CSE/RMK/Augu»t  16, 


fault-tolerance  ISSUES  - I 


• VARIABLE  MODULAR  REDUNDANCY 

- Specify  Redundancy  of  Each  Individual  Task 

- Redundancy  Matches  Criticality 

- No  More  Copies  Than  Necessary 

• GLOBAL  VERIFICATION 

- Consensus  Defines  Correctness 

- All  Functions  Observable  and  Predictable 

- Replicated  Global  Scheduler 

- Completed/Started  (CS)  Message: 

- Node  I.D. 

- Started  Task  I.D. 

- Branch  Condition 


UNL/CSE/RMK/D«cemb«r  30,  i»M 


Message  Passing  Robustness  

• Delivery  NOT  GUARANTEED 

. Single  Msg  Error  Detect.  NOT  GUARANTEED 
- ECC  coverage  > (1  - 1 x 1°  6)  Per  msg 

• Repeated  Undet.  Errors  PROBABILISTICALLY  PRE- 
CLUDED 


CS-9M 
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TASK  SCHEDULING 


UNL/CSE/RMK/Au|uit  10,  1909 


FAULT- TOLERANCE  ISSUES  II 


• DISSIMILARITY  BETWEEN  COPIES 

- Dissimilar  Software  and  Hardware 

- Guards  Against  Generic  Faults 

- No  Guarantee  - Knight,  Levenson,  St.  Jean 

- Best  Chance  of  Detecting  Error 

- Only  Chance  of  Masking  Error 


- Implications 

- Different  Numerical  Results 

- Different  Execution  Times 


- Impact  on  Scheduler 

- Min  and  Max  Execution  Time  Limits 

- Vote  on  Branch  Conditions  in  CS  Messages 


UNL/CSE/RMK/Dcecmbcr  20,  100# 
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FAULT-TOLERANCE  ISSUES  - III 


• BYZANTINE  AGREEMENT 
- Definition 

- Agreement  on  All  Messages 

- Validity  of  Agreement 


- Necessity  in  MAFT 

- Consensus  Defines  Correctness 

- Must  Have  Single  Consensus 

- Preconditions  for  Disagreement 

11^“  ~ EnWed  by  Clarity 
Communj cation  - Minimized  by  Busses 

%tbna,?teraCtiVe  C°nSiStenC^  (P-se  et  al.) 
Global  Receipt  of  All  Messages 

' Periodic  Synchronized  Re-Broadcast  Rounds 
Vote  on  Received  Re-Broadcasts 
- Use  Voted  Values  For  All  Scheduling  Decisions 


UNL/CSE/RMK/Dtcembtr  20,  1000 
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IMPACT  OF  FAULT-TOLERANCE 

• ALL  COPIES  DONE  BEFORE  SUCCESSORS  RELEASED 

• MAX  EXECUTION  TIMERS  - ASSURE  PROGRESS 

• CONFIRMATION  DELAY  - MEAN  2.5  SUB. 

- Only  Affects  Successors 

- Efficiency  Requires  Parallel  Paths 

• FAULT-TOLERANCE  LEVELS 

- Single  Asymmetric  (Byzantine)  Fault 

- Double  Symmetric  Fault 

Reliability  Modelling  - l(T10//ir  with  5 Nodes 


UNL/CSE/RMK /December  Mi  IMS 
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MAFT  Timing  Hierarchy 


PERIOD 

T 

SPEC 

DEFINITIOIS 

* BOUNDARY 

SUB-ATOMIC 

Min 

400^5 

I.C.  Rebroadcast 
Period 

Min  Guaranteed 
Task  Duration 

Task  Inter.  Cons. 
(TIC)  Message 

ATOMIC 

Min 

2-2.8  ms 

Highest 
Freq.  Task 

Clock  Sync. 
Period 

System  State 
(SS)  Message  j 

general 
iteration  , 

2* 

Atom.  Per. 

Intermed. 
Freq. Tasks 

System  State 
(SS)  Message  1 

MASTER 

f 

Max  IK  J 
^tom.  Per. 

Lowest 
Freq.  Task 



System  State 
(SS)  Message  1 

UNL/CSE/RMK/ August  16,  1000 
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Scheduling  StabilityProblem 


scheduling 

dictable  variations  in  total  e 

rW  to  variations  in  system  parameters. 


MULTIPROCESSOR  ANOMALIES  - Observation  that 
Makespan  can  be  increased  by. 

- Increasing  Number  of  Processors, 

- Relaxing  Precedence  Constraints, 

- Decreasing  Individual  Task  Durations. 


. DYNAMIC  FAILURE  - Condition  where  all  tasks  execute 
properly  except  that  deadlines  are  missed. 

- Can  occur  in  a fault-free  system, 

- Can  be  induced  by  instability. 


NASA  FM  W-SHOP 


UNL/CSE/HMK/Augu.tl6,  1890 


Sample  Task  System 


UNL/CSE/RMK/Augu»t  IS,  i860 
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Instability  of  Sample  Task  System 


. STANDARD  GANTLCHABI  (max  task  durations) 

PROC  1 
PROC  2 

. MOM-STANnARD  GAN1XXHAEI  (shorten  T3  by  e) 

PROC  1 
PROC  2 

• V\/idAXilAEE£N£^ 

- T3  finished  before  T2, 

- T6  "ready"  before  T5, 

- T5  displaced  by  T6  =>  Priority  Inversion, 

- Critical  path  (T2  -»  T7)  impeded. 

NASA  FM  W-S1IC 

t)NL/C3E/KMK/Augu«t  16,  1990 
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Previous  Work 


• GRAHAM  (1969)  - Bound  Magnitude  of  Instability 


u>  N 


- U)  — Makespan  of  Standard  Gantt  Chart, 
^ Makespan  of  worst-case  schedule, 

~ ^ Number  of  Processors. 


• MANACHER  (1967)  - Slabifeatior  Algorithm 
Necessary  Pre-conditions 


i.  3 fork”  in  Precedence  Graph, 

of  forking  task  run  in  parallel  on  Sta 
dard  Gantt  Chart, 


n- 


Poss'ble  priority  inversion  around  fork. 

Solution  - Impose  Artificial  Dependency  around  fork. 


UNL/CSE/RMK/Augu»t  IS,  1990 
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Stabilized  Task  System 

. manacher  artificial  dependency  (T,  - r.) 


• EFFECT 

- T2  is  common  parent  for  both  T5  and  T6 

- T6  will  be  "ready"  no  earlier  than  T5, 

_ X5  precedes  Tg  in  priority  list, 

- T6  can  not  be  selected  before  T5. 


NASA  FM  W-SHC 
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Limitations  of  Manacher’s  Solution 


• Sufficient,  but  not  always  necessary 

• Adds  Scheduling  Overhead  (resolve  edge) 

• Unrealistic  System  Model 

Assumes  no  scheduler  overhead, 

- Assumes  dynamic  allocation, 

- Allows  for  no  Confirmation  Delay, 

- Ignores  minimum  duration  bounds, 

- Does  not  predict  magnitude  of  instability. 
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r.lirrent  Research 

. Find  Necessary  and  Sufficient  Stability  Conditions. 

• Develop  Stabilization  Strategies 

- Task  System  Stabilization 

• Edge  Stabilization  (Manacher) 

• Vertex  Stabilization 
. Hybrid  Stabilization 

- Run-Time  Scheduler  Stabilization 

• Limited  Scan  Depth 

- Scheduling  Algorithm  Stabilization 

• Sched.  Algorithm  Assigns  Priorities 

■ Constrain  to  Preclude  Necessary  Conditions 

• Extend  System  Environment 

- Scheduler  Overhead 

- Static  Allocation 

- Confirmation  Delay 

- Minimum  Duration  Bounds 


IINL»/CSB/HMK/Augu»t  16'  1»#° 
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SYNCHRONIZATION 


UNL/CSE/RMK/Augurt  16, 1680 
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MAFT  Synchronization 

• Periodically  Exchange  System  State  (SS)  Msgs 

SS  Msg  =>•  "Atomic  Period"  Boundary 

- Synchronization  Period  = 2 Atomic  Periods 

• Loosely  Synchronized  Individual  Clocks 

- Msg  Exchange  =»  No  Separate  Clock  Lines 

- Physical  Separation  =►  Damage  Tolerance 

- Robustness  to  “Common  Upset"  events 

• Synchronization  Modes 

- Steady  State  - Maintain  Existing  Synchronization 

- Warm  Start  - Converge  to  Existing  Operating  Set 

- Cold  Start  - Form  Initial  Operating  Set 

• Interactive  Convergence  to  synchronize 

• Interactive  Consistency  =>  Steady  State 

• Origin  of  Two-phase  algorithm 


UNL/CSB/RMK/ August  10.  1»»0 
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data  handling  and  voting 


UNL/CSE/HMK/Augu*i  16,  1600 


,e  = 7 nsec  - 600  ft.  separation 
• p = 5 • 10  5 

,r  = 20  msec  =>  10  msec  Atomic  Pd.  =>  100 


• pR  = 1 /xsec 


• No  Faults:  Max  6 = 8.5/x  sec 

• With  Faults:  Max  6 = 16.5/x  sec 


UNL/CSE/HMK/Augu*l  16, 


Data  Management 

• DATA  GENERATED  BY  AP 

• BROADCAST  IN  DATA  MESSAGE 

• RECEIVED  AND  PROCESSED  BY  ALL  NDOES 

Static  Limit  Check 
~ On-The-Fly  Vote 
“ Dynamic  Deviance  Check 


UNL/CSE/RMK/Augu»»  l(,  jmi 
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On-The-Fly  Voting  I 

• TRIGGERED  by  data  message  arrival 
. DATA  ID  ACTS  AS  UNIQUE  VARIABLE  NAME 

. USE  ALL  PREVIOUS  COPIES  OF  SAME  DATA  ID 

- MS  or  MME  (programmer  selectable) 

. Sort  Serially  - High-Order-Bit  First 
. Select  2 “Medial”  Values 

• Average  (Add  and  Shift) 

- No  I.C.  Vote  for  Boolean  Types 

• Difficult  to  implelement  round  2 

• Usually  Control  Data  for  Mode  Switch 

• 3 Better  Way  for  Mode  Switch 


CS-9W 


UNL/CSE/RMK/Au*u»U«. 
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On-The-Fly  Voting  II 


• DEVIANCE  CHECK 

- Compare  Each  Copy  to  Voted  Value 

- Excessive  Difference  =>  error 

- Programmer  Sets  Limits 

- Generate  Error  Vector  =>  Source  Nodes 


• TERMINATE 

- Scheduler  Says  All  Copies  Done 

- Send  Error  Vector  to  Fault-Tolerator 

- Send  Voted  Value  to  Data  Memory 

- Swap  On-line/Off-line  Buffers  in  Data  Memory 

- Clear  Previously  Received  Copies  from  Voter 


UNL/CSE/RMK/Au*u»t  18, 1080 
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ERROR  HANDLING  AND  RECOCVERY 


CS-990 


UNL/CSB/RMK/Au«u»U«,  1»»» 


'T 


F&ultClassifications 


• BYZANTINE  (MALICIOUS) 

Pease  et  al.  (1982) 

-N>  3t  + l 

- r > t 


• MALICIOUS  u BENIGN  (self-evident) 

Meyer  and  Pradhan  (1987) 

- t = m + b 

- N > 3m  -f-  b -f-  1 

- r > m 


• (ASYMMETRIC  u SYMMETRIC)  u BENIGN 

Thambidurai  and  Park  (1989) 

-iV>3a  + 2s-f&  + r-fl 

- r > a 


UNL/CSE/RMK/Augu.l  17,  1900 
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Fault  Classes  by  Source 


• Can  Estimate  Separate  A’s 

- Ksym  « 10"6 

_ \ « 10-3 . . • io-4 

s'sym 

. Generic  Fault  = Multiple  Symmetric 

- A pen  « IO"5  ? 


NASA  FM  W-SHOl 
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Error  Detection 


• Errors  Are  Manifested  In  Messages 

- Physical:  ECC.  framing,  length 

- Contents:  values 
Timing  or  sequencing 
Existence  or  non-existence 

• Log  Errors  Over  One  Atomic  Period 

- Errors  reported  by  all  subsystems 

- Fault-Tolerator  records  errors 

- 3 31  separate  error  "flags" 

- 3 Unique  “Penalty  Weight"  PW  for  each  flag 

- 3 "Incremental  Penalty  Count"  IPC  for  each  node 

- FOR  each  flag  / reported  against  node  i : 

• IPC(i ) :=  IPC(i)  + PW(f) 


UNL/CSE/RMK/Augu*t  17,  1980 
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Error  Reporting 


• Broadcast  ERR(t)  Message 

- At  beginning  of  next  Atomic  Period 

- Contents: 

• IPC{i) 

■ BPC(i)  - Base  (current)  penalty  count 

• All  Error  Flags  for  node  i 

• No  ERR  Message  =>  No  Detections 


UNL/CSE/RMK/Auju»l  17,  198# 
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BPC  Manipulation 


• BPC  Health  Of  Node 

• Increasing  BPC  - ERR  Message  Vote 

- Vote  on  BPC(i ) 

- Vote  on  IPC(i) 

- BPC(i)  ~ BPC(i)  + IPC(i) 

• Decreasing  BPC  — Fixed  decrement 

- 3 Penalty  Decrement  value  PD 
" At  New  Master  Period 

- BPC(*)  :=  BPC{ *)  - PD 
Allows  For  Eventual  Readmission 


UNL/CSE/RMK/Augu*t  17,  1980 
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Exclusion/Readmission 


• Recommend  Exclusion/Readmission 

- 3 Exclusion  Threshold  Texc\ 

- 3 Admission  Threshold  Tadm 

- Recommend  in  next  SS  message: 

• BPC(i)  > Texd  =>  Exclude  i 

• BPC(i)  < Tadm  =*  Readmit  i 

■ Tadm  < BPC(i)  < Texcl  =>  No  Change 

• I.C.  Vote  on  Recommendations 

- Consistent  System  State  is  Critical 

- Free  (needed  for  cold-start) 

- Highly  Degraded  Systems 

- Common  Mode  Upset  Recovery 


UNL/CSE/RMK/Augu*t  17,  IMS 
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time 


*-  - — ► 


■H  Ha/s^I-I/Is  6- - Cs/'V/’t&t  I.c) 


Sed  Quis  Custodiet  . . • HI 


. Ap  _ Diagnostics  in  Workload 


# OC  - System  Level  Self-Test 

- Errors  Very  Rare 

- Inject  Faults  to  Excercise  Error  Detection 

. Special  self-test  Task  ID 
■ Suspend  normal  Transmitter  Ops 
. Tranmsit  string  from  self-test  ROM 
. Can  transmit  ANY  test  scenario 

- Test  Results  Based  On 

• False/Missed  Accusations 

• Cyclic  Link  Check 

- Independent  of  Actual  Bit-Stream 

- Rotate  "Originator"  Duty 

- Complete  Coverage  If  ANY  One  Node  Correct 


UNL/CSE/RMK  / Au*u»t  17,  !#•» 


Version  Management 


• SSV  = System  State  Vec  - eg  (2,1,1) 

• VMV  — Version  Management  Vec  - eg  (1,1,1) 

• WMV  = Workload  Management  Vec  - (SSV)  or  (VMV) 

• Vectors  Used  By  Different  Subsystems 

Sch  ft  ,SA«V  ,naCt.'Ve  C°Py  Sti"  Monitored 

— ' - 6- WMV  Inactive  Copy  May  Not  Run 

WMV  = SSV 


- Inactive  Copy  Still  Executing 

- Actual  Tasks  Being  Monitored 

- Best  for  Generic  Fault  Detection 


• WMV  = VMV 

- Inactive  Copy  Doing  Something  Else 

- Will  Not  Be  AfTected  By  Generic 

- Can  Activate  To  Replace  Sibling 
Best  For  Generic  Recovery 

UNL/CSE/RMK/Aufu»t  17,  ID 8 B 
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Synchronizer  Error  Detection 


• MAFT  error  detection  is  by  consensus 

- Each  node  reports  errors  on  all  nodes. 

- Majority  vote  confirms  or  denies  accusations. 

- Disagreement  with  majority  may  itself  be  an  error 

• Faulty  node  must  be  detected  by  majority  of  nodes 

- Must  be  “far  enough”  out  of  sync 

- There  exists  a region  of  ambiguity 

- Defines  size  of  “Sync  Window 


NASA  FM  W-SHOP 
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Synchronizer  Error  Windows 


P q 


Wh  = ll€+  IQpR 


time 


• ws  = SOFT  ERROR  WINDOW 

- Spans  Range  of  Receipts  from  Non-Faulty  Nodes 

- Error  May  Not  Be  Confirmed 

- Inherent  Ambiguity 

Must  Suspend  Error  Disagreement  Penalties 


• Wh  = HARD  ERROR  WINDOW 

- IF  Any  non-faulty  node  detects  a Hard-Error 
THEN  All  non-faulty  nodes  detect  an  Error 

- Can  demand  Corroboration 


UNL/CSE/RMK/Augiut  16,  1000 
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Typical  Sync.  Window  Values 

• e = 7 nsec  - 600  ft.  separation 

• p = 5 • 10~5 

. R = 20  msec  =>  10  msec  Atomic  Pd.  =>  100  Hz. 

• pR  — 1 /isec 

• No  Faults:  Max  <5  = 8.5 /x  sec 

• With  Faults:  Max  6 = 16.5/x  sec 

m Ws  = 40jx  sec 

» 

• Wh  = 87 n sec 
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SUMMARY 
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SUMMARY  COMMENTS  ON  THE  APPLICATION  OF  MAFT  TECHNOLOGY 


1.  CAPABILITIES 

- BASIS  OF  A GENERIC  REAL-TIME  MULTICOMPUTER  SYSTEM 

- REMOVES  F.T.  OVERHEAD  FROM  APPLICATION  PROCESSOR 

- HANDLES  ALL  REDUNDANCY  MANAGEMENT  WITHIN  COMPUTER 

- ASSISTS  IN  REDUNDANCY  MANAGEMENT  OF  I/O  SYSTEM 

2.  FLEXIBILITY 

- INDEPENDENT  OF  I/O  ARCHITECTURE 

- HIGHLY  RECONFIGURABLE  AND  GRACEFULLY  DEGRADABLE 

- PROVIDES  MECHANISMS/  NOT  POLICIES 

3.  USABILITY 


March  19/ 


1985 


ADVANTAGES  OF  APPROACH 


- PARTITIONED  APPROACH  SIGNIFICANTLY  REDUCES  PROCESSOR  OVERHEAD 

- DATA  DRIVEN  ARCHITECTURE  MUCH  FASTER  THAN  SOFTWARE  IMPLEMENTATION 

- NOT  DEPENDENT  UPON  ARCHITECTURE  OF  APPLICATION  PROCESSOR 

- REDUNDANCY  IS  “TASK-BASED"  AND  FLEXIBLE 

- SUITABLE  FOR  HIGH  RELIABILITY  AND  HIGH  PERFORMANCE  APPLICATIONS 


April  1/  1985 
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VALIDATION  OF  ULTRA-RELIABLE  SYSTEMS 


Achieving  Ultra-Reliable  Software 
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Design  Diversity 

1.  Separate  Design/Imp].^,^  T 
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The  Big  Problem  For  Design  Diversity  Advocates 


I * 

r9  Ph 


O .pH 

p a 

' d 


o 

d 

§ 

d 

<D 

1 

O 

o 

d 

<D 

<D 

o 

nd 

d 

d 

0) 

<D 

id 

Ph 

<D 

/-H 

d 

<D 

Ph 

0 d 
i2  M § 

8 -2  >> 


8 a « 

Ph  <D  O 


d t-H 

• H 

<D 

p d 

*cd  ^ 

is  <l> 

g 53 

O £ 


How  do  we  get  ultra-reliable  numbers  for  hardware  (physical 
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The  Danger  of  Design  Diversity  (N-version  Programming,  Recovery 

Blocks,  etc.) 
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Design  For  Validation 
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This  is  accomplished  analytically. 


Suppose  we  must  design  a simple  fault-tolerant  system  with  a probability  of  failure  no  greater 
than  2 x 10~6  whose  maximum  mission  time  is  10  hours. 
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there  is  a single-point  failure  in  our  system  an  include  it  in  our  reliability  model 
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Rom  this  » we  know  that  C must  be  between  9.9  and  1.0  in  order  to  meet  our  reliability  goal 
rerun  the  model  to  get  at  closer  value. 
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Designing  System  with.  Much  Higher  Reliability 


The  value  of  C must  now  be  greater  than  0.9999982. 

It  can  be  shown  that  over  a million  fault  injections  would  be  required  to  measure  this  parameter 
even  if  we  are  very  optimistic  about  the  testing  process 

If  each  injection  required  1 minute,  this  would  require  almost  1.9  years  of  non  stop  fault  inj 


A better  Way — via  Design  For  Validation 
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What  FM  can  offer  DFCS  Design 


John  Rushby 

Computer  Science  Laboratory 
SRI  International 
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Overview 

• What  has  actually  gone  wrong  in  practice? 

• What  is  the  pattern? 

• What  is  the  solution? 
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Advanced  Fighter  Technology  Integration 

(AFTI)  F16 


• Triplex  DFCS  to  provide  two-fail  operative 
design 

• Analog  backup 

• Digital  computers  were  not  synchronized 

• “General  Dynamics  believed  synchronization 
would  introduce  a single-point  failure  caused 
by  EMI  and  lightning  effects” 


AFTI  F16  DFCS  Redundancy  Management 

• Each  computer  samples  sensors 
independently,  uses  average  of  the  good 
channels,  with  wide  threshold 

• Single  output  channel  selected  from  among 
the  good  channels 

• Output  threshold  15%  plus  rate  of  change 

• Four  bad  values  in  a row  and  the  channel  is 
voted  out 
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AFTI  F16  Flight  Test,  Flight  15 

Stores  Management  System  (SMS)  relays 
pilot  requests  for  mode  changes  to  DFCS 

An  unknown  failure  in  the  SMS  caused  it  to 
request  mode  changes  50  times  a second 

DFCS  responded  at  a rate  of  5 mode 
changes  per  second 

Pilot  said  aircraft  felt  like  it  was  in  turbulence 

Analysis  showed  that  if  aircraft  had  been 
maneuvering  at  the  time,  DFCS  would  have 

failed 


AFTI  F16  Flight  Test,  Flight  36 

• Control  law  problem  led  to  "departure"  of 
three  seconds  duration 

• Sideslip  exceeded  20°,  normal  acceleration 
exceeded  -4g,  then  +7g,  angle  of  attack 
went  to  —10°,  then  +20°,  aircraft  rolled 
360°,  vertical  tail  exceeded  design  load, 
failure  indications  from  canard  hydraulics, 
and  air  data  sensor 

• Side  air  data  probe  blanked  by  canard  at 
high  AOA 

• Wide  threshold  passed  error,  different 
channels  took  different  paths  through  control 
laws 

• Analysis  showed  this  would  cause  complete 
failure  of  DFCS  and  reversion  to  analog 
backup  for  several  areas  of  flight  envelope 
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AFTI  F16  Flight  Test,  Flight  44 


• Asynchronous  operation,  skew,  and  sensor 
noise  led  each  channel  to  declare  the  others 
failed 

• Analog  backup  not  selected  (simultaneous 
failure  of  two  channels  not  anticipated) 

• Aircraft  flown  home  on  a single  digital 
channel 

• No  hardware  failures  had  occurred 
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AFTI  F16  Flight  Test 


• Repeated  channel  failure  indication  in  flight 
was  traced  to  roll-axis  software  switch 

• Sensor  noise  and  asynchronous  operation 
caused  one  channel  to  take  a different  path 
through  the  control  laws 

• Decided  to  vote  the  software  switch 

• Extensive  simulation  and  testing  performed 

• Next  flight,  same  problem  still  there 

• Found  that  although  switch  value  was  voted, 
the  unvoted  value  was  used 
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X29  Flight  Test 


• Three  sources  of  air  data  on  X29A:  nose  and 
two  side  probes 

• If  value  from  nose  is  within  threshold  of  both 
side  probes,  use  nose  probe  value 

• Threshold  is  large  due  to  position  errors  in 
certain  flight  modes 

• If  nose  probe  failed  to  zero  at  low  speed  it 
would  still  be  within  threshold  of  correct 
readings 

• Aircraft  would  become  unstable  and  “depart" 

• Caught  in  simulation  but  162  flights  had 
been  at  risk 
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HiMAT  Flight  Test 


• Single  failure  in  redundant  uplink  hardware 

• Software  detected  this,  and  continued 
operation 

• But  would  not  allow  the  landing  skids  to  be 
deployed 

• Aircraft  landed  with  skid  retracted,  sustained 
little  damage 

• Traced  to  timing  change  in  the  software  that 
had  survived  extensive  testing 
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Gripen  Fight  Test,  Flight  6 


Unstable  aircraft 

Triplex  DFCS  with  Triplex  analog  backup 

Yaw  oscillations  observed  on  several  flights 

Final  flight  had  uncontrollable  pitch 
oscillations 

Crashed  on  landing,  broke  left  main  gear, 
flipped 


Traced  to  control  laws 


Space 

• Voyager  computer  clocks  skipped  8 seconds 
at  Jupiter  due  to  high  radiation  levels 
(AW&ST  Aug  7,  1989) 

• So  ‘‘continuous  resynchronization”  provided 
at  Neptune 

• Also,  remember  STS-1:  ‘‘The  bug  heard 
round  the  world”  (SEN  Oct  1981) 
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FDIR  and  Crew  Interface 


• Imaginary  crash  scenario 

• Broken  fan  blade  on  port  engine 

• Port  vibration  sensor  saturates,  limiter  cuts  in 

• Vibration  travels  down  wing,  shakes 
starboard  engine 

• Starboard  vibration  sensor  reports  the 
attenuated  vibration 

• Only  starboard  vibration  warning  light  comes 
on  in  cockpit 

• Pilot  shuts  down  the  good  engine,  crashes 
short  of  runway 

• Similar  to  British  Midland  737  crash  in  1989 
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Complexity  and  Integration 


• “TheFMS  of  the  A320  ‘was  still  revealing 
software  bugs  until  mid-January/  according 
to  Gerard  Guyot  (Airbus  test  and 
development  director).  There  was  no 
particular  type  of  bug  in  any  particular 
function,  he  says.  ‘We  just  had  a lot  of 
flying  to  do  in  order  to  check  it  all  out. 

Then  suddenly  it  was  working,'  he  says  with 
a grin”  (Flight  International,  27  Feb  1989) 

• The  ATF  hardware  is  ready  to  go,  but 
cannot  be  flown  because  the  software 
engineers  “can't  get  all  the  0’s  and  l's  in  the 
right  order”  (Northrop  Engineer,  7 Aug, 
1990) 
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Complexity  and  Integration 


As  of  early  1988 

A300 

A310 

A320 

Put  in  service 

1982 

1983 

1988 

Number  in  service 

16 

149 

3 

Flight  Hours 

16,000 

810,000 

2,000 

— 

Computers 

Autopilot 

Rudder 

Autothrottle 

Slats  and  flaps 

Elevator/aileron 

Spoilers 

Fuel  management 
Instruments 
Brakes 
Engines 

2 FCC 
2 FAC 
1 TCC 

2 FCC 
2 FAC 

1 or  2 T CC 

2 SFCC 
2 EFCU 
2 FLC 

2 CGCC 

3 SGU 

2 FADEC 

2 FMGC 
2 FAC 

2 SFCC 

2 ELAC 

3 SEC 

3 DMC 
2 BSCU 
2 FADEC 
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Analog,  Mechanical  Backups 


• Do  mechanical  and  analog  backups  reduce 
the  requirement  for  ultra-reliability  in  DFCS? 

• Not  if  the  DFCS  is  providing  stability 
augmentation  or  envelope  protection 

• Similar  problem  in  ATC — potential  to  move 
traffic  at  higher  rates  than  the  backup  can 
handle 

• No  FA  A certification  credit  for  mechanical 
rudder  and  trim-tab  on  A320 
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Analysis:  Dale  Mackall,  NASA  Engineer 
AFTI  F16  Flight  Test 

• Nearly  all  failure  indications  were  not  due  to 
actual  hardware  failures,  but  to  design 
oversights  concerning  asynchronous 
computer  operation 

• Failures  due  to  lack  of  understanding  of 
interactions  among 

o Air  data  system 

o Redundancy  management  software 
o Flight  control  laws 
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FLIGHT  CONTROL  SYSTEM 
RELIABILITY  HEAVILY  DEPENDENT 
ON  SYSTEM  INTERACTIONS 


fUASA 

orni  in  o<)<) 


Analysis:  IMASA-LaRC  1988  FCDS 
Technology  Workshop 

Lack  of  fully  effective  design  and  validation 
methods  with  support  tools  to  enable 
engineering  of  highly-integrated, 
flight-critical  digital  systems 

Complexity  of  failure  containment,  test 
coverage,  FMEA,  redundancy  management, 
especially  in  the  face  of  increased  integration 
of  flight-critical  functions 

Sources  of  failure: 

o Multiple  independent  faults  (never 
observed) 

o Single  point  failures  (observed  sometimes) 
o Domino  failures  (most  common?) 


Analysis:  Scientific  Foundations 


• It  is  time  to  place  the  development  of 
real-time  systems  on  a firm  scientific  basis. 
Real-time  systems  are  built  one  way  or 
another  because  that  was  the  way  the  last 
one  was  built.  And,  since  the  last  one 
worked,  we  hope  that  the  next  one  will. 
(Fred  Schneider) 

• “Not  far  from  there  (CNRS-LAAS),  Airbus 
Industries  builds  the  Airbus  A320s.  These 
are  the  first  commercial  aircraft  controlled 
solely  by  a fault-tolerant,  diverse  computing 
system.  Strangely  enough  this  development 
owes  little  to  academia.  (IEEE  Micro,  April 
1989,  p6) 
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Analysis 


• The  problems  of  DFCS  are  the  problems  of 
systems  whose  complexity  has  exceeded  the 
reach  of  the  intellectual  tools  employed 

• Intuition,  experience,  and  techniques  derived 
from  mechanical  and  analog  systems  are 
insufficient  for  complex,  integrated,  digital 
systems 
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Synthesis 


• Computer  science  has  been  addressing  issues 
of  systematic  design,  fault  tolerance,  and  the 
mastery  of  complexity  with  some  (limited) 
success  for  the  last  20  years 

• But  there  has  been  little  interest  in  learning 
about,  and  applying  this  knowledge  to, 
real-time  control  systems  in  general  (and 
little  opportunity  to  apply  it  to  DFCS) 

• And  little  of  the  lore  and  wisdom  of  practical 
real-time  control  system  design  has  been 
captured  and  analyzed 
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What  computer  Science  Can  Otter  DFCS 

systematic  techniques  for  the  construction 

' of  trustworthy  software,  including. 

Techniques  for  the  precise  specification  of 

° T ntc  and  the  development  of 

requirements  and  v 

designs 

• rrincg  "" 

systems 

o Fault  tolerant  algorithms 

O systematic  methods  of  testing  and 
analytic  methods  of  verification 

. where  do  formal  methods  come  inf 
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Applied  Mathematics  and  Engineering 

• Established  engineering  disciplines  use 
applied  mathematics 

o As  a notation  for  describing  systems 

° As  an  analytical  tool  for  calculating  and 
predicting  the  behavior  of  systems 


• Computers  can  provide  speed  and  accuracy 
for  the  calculations 
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Applied  Mathematics  and  Software 

Engineering 


• The  applied  mathematics  of  software  is 
formal  logic 


• Formal  Logic  can  provide 

O A notation  for  describing  software 
designs  —formal  specification 

O A calculus  for  analyzing  and  predicting  the 
behavior  of  systems—  formal  verification 

. Computers  can  provide  speed  and  accuracy 
for  the  calculations 

. Calculating  the  behavior  of  software  is  an 
exercise  in  formal  reasoning— i.e.,  theorem 

proving 
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Formal  Methods 


• Methodologies  for  using  mathematics  in 
software  engineering 

• Can  be  applied  at  many  different  levels,  for 
both  description  and  analysis 

0.  No  application  of  formal  methods 

1.  Quasi-formal  pencil  and  paper  techniques 

2.  Mechanized  quasi-formal  methods 

3.  Fully  formal  pencil  and  paper  techniques 

4.  Mechanically  checked  fully  formal 
techniques 
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of  Formal  Specification 


Benefits 

. unambiguous  description  facilitates 
communication  among  engineers 


. Early  detection  of  certain  errors 

. Encourages  systematic,  thoughtful  approach 
reuse  of  well-understood  concepts 


As  documentation,  reduces  some  of  the 
difficulties  in  maintenance  and  modification 
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Benefits  of  Formal  Verification 


• Subjects  the  system  to  extreme  scrutiny, 
increasing  designers’  understanding  of  their 
own  creation 

• Helps  identify  assumptions,  increases 
confidence 

• Encourages  simple,  direct  designs,  austere 
requirements — better  systems 

• Encourages  and  supports  a systematic, 
derivational  approach  to  system  design 

• Complements  testing  and  allows  it  to  focus 
on  fundamentals 
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Conclusion:  What  FM  Can  Offer  DFCS 

• Precise  notations  for  specifying  requirements 
and  designs 

• Concepts  and  structure  for  systematic  design 

• Intellectual  tools  for  analyzing  the 
consistency  of  specifications  and  the 
conformance  of  designs 

• A way  to  regain  intellectual  mastery  of 
complex  systems  and  their  interactions 
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Recommendations 


• Just  adding  formal  methods  to  existing 
practice  is  inappropriate 

• Capture  and  analyze  lore  and  wisdom  (and 
mistakes)  of  actual  DFCS  designs 

• Apply  modern  Computer  Science  (including 
Formal  Methods)  to  develop  building  blocks 
for  principled  DFCS  design 

• Ultimately,  build  one  and  fly  it! 
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What  Can  Formal  Methods  Offer  to 
Digital  Flight  Control  Systems  Design? 

Formal  Methods  Workshop 
NASA  Langley  Research  Center 
Hampton,  VA. 

August  20-23, 1990 


Donald  I.  Good 
Computational  Logic,  Inc. 


physTc^bSTaviSf  oT^gilil'  haEc  and  TlW^temsWhTh  Z"  mathcmatica]  modeling  of  the 
supports  the  NASA  mission  of  increasing  the  sco^  and  keti 

for^ce^SdmroTr^  " “T***  ***  *s  "«  ad^* 

has  not  had  the  benefits  of  Police  of  digital  flight  control  system  design 

engineering.  C malhcmal“'al  m^ci.ng  which  arc  common  in  other  parts  of  flight  system 


systems! JSSibte. IS^d'sc^  S te  sflfl  iTa^  S*’  ^ mode,inK  of  di8ital 

developed,  they  will  briny  the  traditioml  hfwf.ic  a ,Sl  10  ? .n  cmbry°nic  slage.  But  when  they  are  fully 
reasoning  design.  Soon, I 

ri.sk  of  unsafe  night  cuniroT  8lU  t0n“°l  sysKms  c”  ™ Nmum  par,  of  reducing  ,he 


What  Can  Formal  Methods  Offer 


to 


Digital  Flight  Control 
Systems  Design? 


Donald  I.  Good 


Computational  Logic,  Inc. 

1717  West  Sixth,  Suite  290 
Austin,  Texas  78703 

512-322-9951 

good@cli.com 
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II 


Formal  Methods"  Enable 
Mathematical  Modeling 

of 

Digital  Systems 
(Hardware  and  Software) 


NASA  Mission  ^ 

NASA  HO,  1990. 
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Why  Model? 

aFn  s sjsss;  *; sr m - 

Benefits:  early  error  detection 

• Saves  time 

• Saves  money 

• Saves  operational  disruption 

• Saves  operational  mishaps 

Risks:  model  misrepresents  system 

• Inaccurate 

• Incomplete 

SemaS!e'S:  PhySiCal'  anal09'  “•""Me. 

wS'pSSff  En9ta““' 


Why  a Mathematical  Model? 

• High  abstraction 

• High  precision 

• Simulate  by  manipulating  symbols 

• Represent  large  classes  of  system  states 

• Use  mathematical  deduction 

Get  a lot  of  system  simulation  for  a little  symbol 
manipulation. 
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Operational  Safety 

Operating  a system  safely  requires 

• accurate  predictions 
of  how  it  wjj]  behave. 

Accurate  predictions  can  be  obtained  from 

• sound  deductions  about 

• accurate  mathematical  models 
of  system  behavior. 
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A Classic  Model 


Free  Fall  Distance: 

r_/v>\  * t**2]  / 2 

f(b,t)  = 

, it  b=" earth"  then  32 
g(else  if  b="moon"  then  • • - 

t is  tiro®  (sec) 

£(b,t>  is  distance  (ft) 

Simulation: 

f ("earth" , .7)  = t32  * ’7* 

1 = 16  * -49 

=7.84  ft 
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Power  of  Mathematical  Deduction 

Suppose  0 le  to  le  tl. 
t ^ [to. .tl] 

( earth  , t)  in  (32  * [t0..tl]**2)  / 2 
f ("earth",  t) 

f( "earth",  t) 


in  16  * [to. .tl] 


in  16  * [t0**2 . ,tl**2] 

(**  is  monotonic) 

Physical  simulation  of  this  recnit  >e  i 
because  [to.  tn  res  . ,s ‘mpossible 

values.  ntams  an  infinite  number  of 
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Validating  a Model 

jltimately, the  ^^bevalidSd  by  il 

behavior  of 

actual  physical  system.  matical  proof  that 

One  cannot 

a model  is  an  accurate  repr 
physical  system.  ess  0f 

, Typically,  one  iterates  through  a process 

. statinq  a mathematical  model 
• testing  against  physical  observations 

. adiustinq  the  model 


Hardware  Model  Observables 

A hardware  system 
is  composed 
of  physical  switches. 


An«Cy-  St,em'  INiAC  to  UNIVAC-  An 

Next  page. 
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ORIGINAL  PAGE 

BLACK  AND  WHITE  PHOTOGRAPH 


ORIGINAL  PAGE  IS 
OF  POOR  QUALITY 


Use  Discrete  Mathematics 
to  Model  Hardware 


Switches  by  binary  digits 


Operation  by  recursive  functions 


| 01100001111 


10100110000  | 


s2  | 11100010101  | 


o o o 
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An  MC68020  Machine  Model 


MC  68020 (s, n)  = 

tu  haltP(s)  or  n=0 
then  s 

else  MC68020 (NEXT (s)  , n-l) 

NEXT(s)  = 

if  evenp (pc ( s ) ) 


then  if 


RvF~?i"“fm(S)'PC(3)) 


(s)  , s) 


)) 


then  EXECUTE (FETCH (pc  %w 

else  half/  uPdate_pc( 

else  hti?, halt(s'  Pc  signal) 
else  halt ( s , pc_odd_signal ) 

EXECUTE (ins,  s)  = 

[50  pages  for  90%  user  ins.] 


Yuan  Yu.  PhD 
Texas. 


^Qiesis  {in  firogress).  University  of 


The  VIPER  Machine 

V 32-bit  microprocessor  "erbose  fonctlons  ere 
;otally  predictable. 

• Accumulator 

. 2 index  registers 

• Program  counter 

• Comparison  register 

• 16  instructions 

Avra  Cohn.  4 A^S^whSlaT 

C°"PU,e' 

Laboratory,  January,  1987. 

...  , f'Uiiwer  implementing  High  injgQti^ 

iEEE,  June, 

Computer  Assurance, 

1988. 
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A VIPER  Machine  wo 

next (ram, p,a,x,Y'b' s 

s-  iu— > 

else  f*  (illegalcl  \/  illegaiwr) 

»*”  i pw>  ■ ■ • 

else  • • • *■ 


where 

ram 

P 

a 

x,y 

1 b 
stop 


32-bit  words 
a memory  of  ^ counter 

20-bit  Pr°9r*®  tor 

32-bit  accumulato  rS 

32-bit  re1  result  register 

1 bit  compare 

stop  fla9 
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The  FM8502  Machine 


A 32-bit  microprocessor. 

• 2 address  architecture 
4 addressing  modes 

• 8 general  purpose  registers 

• 219  20-bit  instructions 


Texas  at  Austin,  1985.  S,S’  ^n,versity  oi 

of  Aul°™Sdf^ 

a OI.  o,  No.  4,  Dec  1989 


An  FM8502 
Machine  Model 


™f£02  lS“u>‘p  <“» 1 

3S 


NEXT  (ms)  - (ms)  , 

list (next_memory  file(ms), 

next_register_^  , , 


^x^overrfloilflag(ms) 


next  j 


next  zero  flag  - • 

next-negative_f  lag  (»=)  > 


(ms) 


next 


[about  10  pages] 
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An  FM8502 

Register  Transfer  Model 

GATES  (gs,  gn)  = 

then  gf  (liStp  (gn)  > 
else  GATES  (COMB  LOGIC  tr, 

cdr(gnnC(9S'Car^n)), 

COMB  LOGIC (gs , gn ) = 

fon  bit  operato  e g h 

' e-y*/  b__xor] 


where 
gs 

regs 

flags 

mem 

int-regs 


- 0C32-Ki5lagS'  m®m-  int-re 

- 32  h3?'bit  vectors 
J^-hat  vectors  for  4„*. 

n.».  i«oS‘ 


Connecting  the  Models 


fm8502  (ms, mn) • 


D (ms) 


gates (gs,gn)  


tf(gs) 


“>o 


Theorem:  H(mS/mn)  -> 

fm8502 (ms,mn)  = 

u ^ateS <D(ms),Kg(ms,mn,md))) 

Under  the  conditions  h, 

• ^ fm8502  mode,  ,s  Jus,  as  a 

• but  with  some  detail*  * ~ g tes 

me  oetails  sugfiressed  by  u< 
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Software  Model  Observables 

programming  languages  provide 
a wide  variety  of  ways 
of  describing  them,  but 
the  observables  are  still  switches, 
and  so  are  programs! 
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Models  ol  Programmed  Machines 

A machine  is 

switches  which  itw.ll  mJJP  stored.prograni 
d^^glts operation.  (B  called "setting up 
machines,  this  process  w 
the  machine.) 

7oTi"o 

data 
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A Model  of 

Programmed  Machine 

to SrCSS1?  "»  state  3 
atse-tbed  by  l„  fe  »'  <he  pro*,™ 


where 


M(s0, k (sO) ) 


s 0 


Prog(s) 


a niachine  state  suoh  +-u 
Prog(sO)=p0  h that 

a function  that  extr-a  4. 

Program  descriptio^S  f" 

Operating  Requirements 

A model  of  a marh.v.,.  _ 

operating  requirement  *°  Sa‘isfy  an 

«(so,sk)  is  given  by 
R(s0,  M(sO, k (sO) ) ) 


A Program  Description,  pO 


088B  000D  0002 
OOOr  10CB  0002 
ODCB  0002  0005 

0002  OOOD  104B 

0003  0002  0041 
0000  0002  396B 
0002  984B  0004 
000*  OCDO  000* 
OCCA  004D  0002 
09r3  0089  0008 

0002  OOOA  OBCA 

ooif  ooo*  ocdo 

0003  0080  0841 
ocas  064b  0003 
0003  000c  0006 
000*  0CA8  0002 
0003  00D3  OOCB 
004B  0003  OOBF 
0006  004D  0003 
000*  OCCA  104B 
0006  004D  0003 
0C96  OOCB  0003 
0C96  004B  0003 
0003  0003  09CB 
OOOC  0002  084B 
0002  0007  000* 
OCCA  104B  0003 

0002  0C86  004B 
0041  0003  00r3 
0009  0041  0003 
OOOC  004D  0003 
OOOA  0C86  O08B 

0003  000*  000* 
0006  0C13  104B 
104B  0003  0008 
0041  0002  0100 
0100  000*  0CA8 
OOOC  0003  004B 
09F3  104B  0005 
0002  0009  004B 
004D  0003  0008 
OCCA  0082  OOOA 
00A2  0000  0004 
OCDO  000*  0A29 
0002  02D6  0003 
0041  0004  0004 
0041  0002  0004 


088B  OOOC 
0000  31CB 
OCCB  0002 
0003  000* 

0003  009r 
0000  0002 
0002  784B 
OCCA  000* 
0002  0041 

0004  0083 

0002  0BA5 
088B  OOOC 

0003  0004 
0006  004D 
0C96  OOCB 
0C96  004B 
0003  0002 
000*  OCDO 
0080  0841 
0003  OOOC 

0002  0041 
0000  OlCB 
OOBF  000* 

0003  0006 
0003  0002 
0CA8  00B6 
OOOC  004D 
0003  OOBF 
000*  OCDD 
OOOF  OBCB 

0002  0041 
000*  0003 
09F3  104B 
0002  0008 
004D  0003 
000*  OCBA 
0082  OOOA 

0003  OOBF 
0009  004D 
0003  OOBr 
0041  0003 
004B  0003 
004B  0003 
00A2  0000 
79c 7 0003 
08CB  0004 
1841  0002 


0003  004B  0003 

0002  0000  12CB 
0006  OFCB  0002 
0000  084B  0003 
OODA  0003  OlDE 
lA8B  0000  0003 

0003  0002  S84B 
OCAS  0002  0C86 
0002  00D3  OOCB 
0008  0000  OOOA 
084B  0006  0002 

0002  084B  0004 
0041  0003  01F3 

0003  0002  0041 
0003  0000  OlCB 
0003  OOBF  OOOC 
09CB  0003  0006 
088B  OOOC  0002 
0003  0004  0041 
004D  0003  0009 
0003  OOD3  00C3 
0003  0000  084B 
OCCA  104B  0003 

0002  0C86  084B 
004D  0003  0008 
OOOC  0006  0C96 

0003  0002  0041 
000*  OCDO  088B 
OOOA  OBCC  000* 
0003  0002  0002 
0003  00D3  OOCB 
004B  0003  OOBF 
0005  0008  004D 
004B  0003  OOBF 
0008  0041  0003 
0082  OOOA  00B2 
104B  0002  0009 
000*  OCDD  OOOA 
0005  0002  0041 
000*  0CA8  OOCB 
0173  000*  OCDD 
OOBF  000*  OCDD 
OOBF  000*  OCDO 
0848  0004  0003 
0003  0000  384B 

0002  0000  02D2 

0003  184B  0002 


OOBF  000*  OCDO  004D 
0002  OOOD  13CB  0002 
0007  0041  0002  0006 

0002  004D  0002  0009 

0003  084B  0003  0002 
F84B  0007  0002  D84B 
0002  0002  0000  000* 
000*  09F3  004B  0003 

0002  0001  OlCB  0002 
0A98  0083  0008  0001 
0049  0006  0010  084B 
0006  004D  0004  0008 
000*  0CE1  OOOA  0A*7 

0003  00D3  00C3  0003 
0003  0000  064B  0002 
OCCA  104B  0003  OOOC 

0002  0C86  084B  0006 
084B  0004  0002  004D 

0003  01F3  000*  OCDD 
0041  0003  OOOF  OBCB 
0003  0002  0006  0C96 

0002  0006  004B  0003 
OOOC  004D  0003  0002 
0007  0003  004B  0003 
0041  0003  0173  000* 
00A6  OOOC  0002  0C96 

0003  00D3  OOCB  0003 
OOOC  0002  084B  0003 
OCDO  000*  OCCA  104B 
0C96  004B  0003  OOBF 
0003  0005  OlCB  0003 
000*  OCDD  OOOA  0BT7 
0005  0002  0041  0005 
000*  0GA6  OOCB  0005 
00F3  000*  0CC1  0006 
0008  0006  0C38  104B 
000*  OCAS  0082  OOOA 
0C54  008B  OOOA  0C9F 
0005  00D3  00C3  0005 
0005  0000  OlCB  0005 
008A  OOOA  000*  OCDO 
OOOA  0C95  000*  OCDO 
000*  0A29  00 A*  0000 
0041  0004  0004  3841 
0004  0003  7845  0004 
0003  78C?  0003  0003 
0002  0000  02C3  0003 


0002  0009 
000*  OCCB 
50CB  0002 
0041  0002 
0041  0003 
0006  0002 
09F3  004B 
OOBF  OOOC 
0000  0002 
OOOA  OAFD 
0007  0003 
084B  0003 
084B  0002 

0003  0006 
0006  004B 
004D  0003 

0002  0049 

0004  0008 
OOOA  0B54 

0003  0002 
11C3  0003 
OOBF  000* 
0041  0003 
OOBF  000* 
0CX1  OOOA 
004B  0003 

0004  OlCB 

0002  004D 

0003  OOOC 
000*  OCCA 
0000  0002 
008B  OOOA 
00D3  OOC3 
0000  OlCB 
0C2A  104B 

0002  0009 
008B  OOOA 
104B  0003 
0004  0006 
0000  104B 
088F  0009 
000*  0A29 
0048  0003 
0004  0003 

0003  0841 
0000  084B 
0000  0000 


0041  0002 

0002  0004 
OOOO  104B 
OOOF  004D 

0006  188B 
B84B  0005 

0003  OOBF 
OCDO  000* 
0C86  OOOC 
0083  0008 
004B  0003 

0002  004D 

0007  000* 
0C96  11C3 

0003  OOBF 

0002  0041 
0006  0010 
084B  0003 
OOOC  OCDO 
084B  0003 
OOOC  0006 
OCAS  0002 
00D3  OOCB 
OCDO  088B 
OB0F  084B 
OOBF  000* 

0003  0000 
0003  0008 
004D  0003 
104B  0003 
0C86  008B 
0C9F  104B 
0005  0005 
0005  0000 

0002  0009 
0041  0002 
0C86  088B 
000*  OOOC 
OC70  104B 

0003  0009 
0002  OOOC 
OOBA  OOOB 
OOBF  OOOC 
08CB  0004 

0004  0003 
0002  0003 
7AC3  0003 


[752  16-bit  words] 
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The  Kit  Separation  Kernel 

Uses  a modified  FM8501  (ms, inn)  machine 
Interrupts  for  timer  and  I/O 
Process  management 

• fixed  number  of  processes 

• process  scheduling  (round  robin) 

. process  communication  (message  passing) 

. response  to  error  conditions 

. Device  management  for  character  I/O  to 
asynchronous  devices 

. Memory  management  uses  hardware  protection 


miiam  R.  Bevier.  Kit:  A Study  in  Operating 

oftware  Engineering.  November  1989. 
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‘he  CLInc  Stack 


o — 


uGypsy(yx,yp,yd,yn) 


Compile 


Young 





9 

^■^k-assemble 


piton (ps,pn) 


Moore 


>o 





Reify 


fm8502  (ms,mn) 


Hunt 


>o 


g_di splay 


gates (gs,gn)  _ 


>o 


DeYoung.' journal  ofT^ M°°re William 
5-  No.  4,  Decl989. " BMsonmg.  Vol. 
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The  Piton  Language 

fhe  Piton  language  has 
. execute-only  program  space 
. read/write  global  arrays 
. recursive  subroutine  calls 

• formal  parameters 

• user-visible  stack 

• stack-based  instructions 

• f|ow-of-control  instructions. 

The  cross  assembler  produces  an  FM8502  binary 
core  image. 
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The  Micro  Gypsy  Language 

The  Micro  Gypsy  subset  of  Gypsy  has 

• types  integer,  boolean,  character 

• one  dimensional  arrays 

• parameters03"8  W'*h  pass  b*  reference 

• sequential  control  structures  if,  loop 

• condition  handling  signaLwhen. 

The  compiler  produces  Piton. 
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The  Stack  Theorem 

Theorem:  H' (yx, yp, yd, yn)  -> 

uGypsy(yx,yp,yd,yn)  = 

u (gates (D' (yx, yp, yd) , 

Kg' (yx, yp, yd, yn, md) ) 

Proof:  Mechanically  checked. 

Under  the  conditions  H' , 

• the  uGypsy  model  is  just  as  accurate  as  gates 

• but  with  many  details  suppressed  by  u' 

Boyer-Moore  Logic 

Robert  S.  Boyer,  J Strother  Moore  II.  A 
-^nputationaj  Logic  Handbook,  Academic  Press, 

FnhlKaUfmann'  - Manual  for  an  Interactive 
^^^JfiS^^fofoeBoyeMVfopre  Theorem 
-over-  TR  19,  Computational  Logic,  Inc.,  1988 
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A Hierarchy  of  Models 
of  a Programmed  Machine 

r (yxO , ypO , ydO , ydk) 


uGypsy (yxO,ypO, ydO , yk (yxO , ypO , ydO ) ) 


piton (psO , 
fm8502  (nisO , 
gates  (gsO , 


pk (psO) ) 
mk (msO) ) 
gk (gsO) ) 


Corresponding  to  these  is  a hierarchy  of  program 
descriptions.... 
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Operating  Requirement 

procedure  mult (var  ans : fm8502 int , 

i, j:fm8502_int)  = 

begin 

ENTRY  j ge  0; 

EXIT  ans  = NTIMES (i, j) ; 

pending; 
end; 

type  fm8502  int  = 

integer [- (2**31) . . (2**31)-!] 


{A  Simple  Problem  Domain  Theory} 

function  NTIMES (x, y : integer) : integer  — 

begin 

exit  (assume  result  = 
if  y = 0 then  0 
else  if  y = 1 then  x 

else  x + NTIMES (x,y-l) 
fi  fi) ; 

end; 
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Gypsy  Program  Description 

procedure  mult (var  ans : fm8502_int ; 

i , j : fm8502_int ) = 

begin 

ENTRY  j ge  0; 

EXIT  ans  = NTIMES (i, j) ; 
var  k:fm8502_int  :=  0; 

k : = j ; 
ans  : = 0 ; 
loop 

ASSERT  j ge  0 & k in  [0. . j] 

& ans  = NTIMES (i, j-k) ; 
if  k le  0 then  leave  end; 
ans  :=  ans  + i; 
k : = k - 1 ; 

end; 

end; 
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FM8502  Program  Descripti 


(H-s  TATI 


'!psssssss^ss 


'S^s^ssssas 

=5SS 

SSS 
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P=i=H! 

srsssssssr22^ : 
=:=srSS» 
=hsss=h 

skks££kk::: 

ssssssssssr^s:  s 

r*S=: 

sssx^sssss 

Booooooooooooinn0ooooi°nn10001100  800 


===== 

ispi 


illlllS S 

Mi 

sssassS5525 

ssssssS222 
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ssrssS55® 
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Mathematical  Requirements 

• Unambiguous:  Requirements  have  a well- 
defined  interpretation  that  tells  exactly  what 
they  do  say. 

• Analyzable:  Do  the  requirements  say  the  "right" 
thing? 

R(x, y)  ->  good_thing(x,y) 

• Consistency:  Requirements  contain  no 
contradictions. 

• Enable  modeling  a program  component  before 
building  it  (and  thereby  save  the  time  and  cost 
of  designing  a poor  program.) 

To  get  these  benefits,  the  requirements  notation 

must  have  a rigorous  mathematical  foundation 

(semantics). 
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\ ^ 

Design  » Requirements 

• There  is  more  to  designing  a digital  system  than 
just  stating  and  refining  mathematical 
requirements. 

• One  must  still  construct  a program  for  some 
machine. 

• Mathematical  models  of  commonly  used 
languages  and  machines  are  still  very  scarce. 
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Summary 

For  either  design  of  a new  system  or  operation  of 
an  oid  one,  mathematical  modeling  of  digital  flight 
control  systems  offers 

Benefits:  early  error  detection 

• Saves  time 

• Saves  money 

• Saves  operational  disruption 

• Saves  operational  mishaps 

Risks:  model  misrepresents  system 

• Inaccurate 

• Incomplete 
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High  Level  Design  Proof  of  a 
Reliable  Computing  Platform 
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Architectural  Concept 


Design  Decisions 


\p  = permanent  fault  rate  (~  10-4/hr) 
p = rate  of  recovery  from  transient  fault  (design-dependent) 


Application  Definition 


IR:  initial  task  inputs 


Task  Schedule 
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A Simple  Fault  Model 


e correctness  are  predicated  on  this  assumption. 
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Nr  = Lc  + Ln  + M where 
_ Lc  = maximum  frame  length  for  all  cycles 
_ r»r  = maximum  frame  length  for  all  noncyclic  paths 
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mod_proof : PROVE  mod_induction  dl  <-  dlQpl,  d3  <-  dlQpl,  d4 
FROM  gener al_induct ion  p <-  (LAMBDA  d : A(d)  IMPLIES  B(d)) 
END  noetherian 
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safe  a <-  d4@pl,  c <-  d3@pl 
inductive_step  c <-  dlOpl 


Formal  specification  and  verification  revealed  typos  in  the 
original  report 
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We  have  the  beginnings  of  a formally  verified  model  for  a 
fault  tolerant  operating  system 


The  Design  and  Proof  of  Correctness 
of  a Fault-Tolerant  Circuit  ^ • 


William  R.  Bevier 
William  D.  Young 


Computational  Logic,  Inc. 
1717  W.  6th  Street 
Austin,  Texas 


What  We  Accomplished 


• A formal  statement  of  Interactive  Consistency  Conditions1  in  the 
Boyer-Moore  logic. 

• A formal  statement  of  the  Oral  Messages  algorithm  OM  in  the  Boyer- 
Moore  logic. 

• A mechanically  checked  proof  that  OM  satisfies  the  Interactive 
Consistency  conditions. 

• A mechanically  checked  proof  of  the  optimality  result:  no  algorithm 

can  tolerate  fewer  faults  than  OM  yet  still  achieve  Interactive 
Consistency. 

• The  use  of  OM  in  a functional  specification  for  a fault-tolerant  device. 

• A formal  description  of  the  design  of  the  device. 

• A mechanically  checked  proof  that  the  device  design  satisfies  the 
specification. 

• An  implementation  of  the  design  in  programmable  logic  arrays. 


*See  "The  Byzantine  Generals  Problem" 
No  3,  July  1982. 


Lamport,  Shostak  and  Pease,  ACM  Toplas,  Vol  4, 
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The  Specification 


The  specification  is  a function  that  describes  a finite  state  machine. 


At  every  step,  each  of  N processes 

1.  reads  its  sensor  input, 

2.  exchanges  its  sensor  value  with  all  other  processes, 

3.  produces  an  interactive  consistency  vector  (ICV)  that  contains  what  it 
concludes  is  each  other  process’s  value,  and 

4.  applies  a filter  function  to  the  ICV  to  produce  an  output. 
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Properties  of  the  Specification  Function 


The  exchange  of  sensor  values 


is  accomplished  by  an  algorithm  called  OM. 


OM  achieves  inter ac- 


tive consistency.  That  is, 


A process  sends  a message  to  n-l  destina^^  P ^ same  received 

1.  All  non-faulty  destination  processes  agree 

value'  • f,„i,v  then  every  non-faulty  destination 

2 If  the  sending  process  is  non- 
’ nrocess  receives  the  message  sent. 


OM  has  been  defined  as 


a function  in  the  Boyer- 


Moore  logic,  and  a proof  that 


interactive 


consistency  is 


achieved  has  been 


mechanically  checked. 
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Formal  Statement  of  Correctness  of  OM 


• n be  the  number  of  processes, 

• L be  the  set  {0, n - 1 }, 

• ij  e L be  process  names, 

• x be  g’s  local  value,  and 

• m give  the  number  of  rounds  of  information  exchange. 


The  interactive  consistency  conditions  are  stated  as  follows. 

faulty  (i) 

& —ifaulty(j) 

& 3 faults  (L ) < n 
&faults(L)  < m 

— > 

OM(n,  g,  x,  m)l ij  = OM(n,  g,  x,  m)ljj, 


—ifaulty(g) 
&-\faulty(i) 
&3faults(L ) < n 
&faults(L)  < m 


OM(n,  g,x,  m)[ij  = x 


Specification  Abstraction 


e specification  arc  not  constrained: 


XI ic  following  aspects  of  the 

1 . The  number  of  processes. 

2.  The  types  of  the  input  and  output  values. 

3 The  nature  of  the  filter  function 


What  Interactive  Consistency  Guarantees 


The  specification  can  be  thought  of  as  a function  which 

• receives  a sequence  of  ^-tuples  of  input  values,  and 

• produces  a sequence  of  AMuples  of  output  values. 


Because  of  Interactive  Consistency, 


we  can  conclude: 


At  each  step,  all  non-faulty  processes  agree  on  their  output  iff  the  total  number  of 
processors  exceeds  three  times  the  number  of  faulty  processors. 
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A Process  Internal  State 


data_in 
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Process  Steps 


del 1 3 out  l i 1 
iev [3] 
clock 

m [ 0 , i ] 
dat  a__out  [ 0 ] 
data_out l 1 ] 
data_out [ 2 ] 
clock 

m [ 1 , i ] 

data_out [ 0 ] 
data__°ut  [ 1 ] 
data_out [2] 
clock 


4—  sense,  i&  (0,1,2) 
e-  sense 
4-  clock+1 

<—  input  [x]  , iz  (0,1,2) 
4—  input  1 1 J 
4—  input  1 0 ] 

4—  input  [ 0 ] 

4—  clock+1 


4—  input  l i . 
4—  m [ 0 , 2 ] 

4—  m [ 0 , 2 ] 

4—  m [ 0 , 1 ] 

4—  clock+1 


le  (0,1,2) 


m ( 2 , i ] 
clock 

4—  input  [i],  (0,1,2) 

4—  clock  t- 1 

; icv(O)  <“ 

iev  ( 1 ] <— 

iev [2]  <- 

clock 

majoril  y(m|0,01,  mil, 2], 
majority  (in  (0,  1 1 / ml  ,0  , 

major  i t y (in  ( 0 , 2 ] , m 1 1 , 1 1 , 
clock+1 

: Actuator 

clock 

4-  filter (iev) 
4—  clock+1 

: clock 

4—  clock+1 

: clock 

4—  clock+1 

m [ 2 , 1 ] ) 
m [ 2 , 2 ) ) 
m [ 2 , 0 ] ) 
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Summary  of  Device  Design 


1.  Four  identical  devices. 

2.  Only  internal  and  external  data  flow  specified,  data  width  not. 

3.  Filter  function  constrained  to  tolerate  ICV  rotations. 


Device  Implementation 

by  Larry  Smith 
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Verifying  an  Interactive  Consistency  Circuit: 

A Case  Study  in  the  Reuse  of  a Verification  Technology 


Mark  Bickford 
Mandayam  Srivas 

Odyssey  Research  Associates,  Inc 
301A  Harris  B.  Dates  Drive 
Ithaca,  NY  14850. 


ive 


This  talk  presented  the  work  ofYsJhe^for 

and  f°r"al  verifioatronoOfiathard. '^byzan?ine  agreement)  among  four 

microprocessors  . The  microprocessors^used^in  tl]1®3^=^"0®Ip1pelined, 
^fprolesso?"  toniCayuga . YThS  4-processor  system,  which  is  designed 

S^hf  assuror > that  the  clocks  of : all  ^ Proces-rs^are 

synchronized,  provides  =°ftware  contro  computation  is 

consistency  operation.  Interact!' ve> c°“s  ® i the  microprocessors  . 

1 sSs£SS.j^Ss,„ 

designs.  MimCayuga  was  verifie  u | ± t in  reUsing  this  technology 
which  was  also  developed  at  ORA.  To  assist  in  re  ^ developed. 

This^toot ^specializes "cl io  to^synchronous  £^yt£^"S«igns . 

?if^ik  presen?eS  ?he  ?ool  and  described  how  it  was  used  to  specify 
and  verify  the  interactive  consistency  circuit. 


Summary 


Achievements 

1 . Formalization  of  abstract  Byzantine  agreement  algorithm. 

2.  Use  of  this  algorithm  to  specify  a hardware  device. 

3.  A mechanically  checked  proof  that  the  device  design  is  correct. 

4.  The  implementation  of  the  device  form  the  low-level  design. 

Limitations 

I . Assumes  synchronized  behavior  of  the  processes. 
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Verifying  an  Interactive  Consistency 

Circuit: 

A Case  Study  in  the  Reuse  of 
a Verification  Technology 


Mark  Bickford 
Mandayam  Srivas 


Odyssey  Research  Associates,  Inc. 
301A  Harris  B.  Dates  Drive 
Ithaca,  NY  14850. 
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Objectives  of  the  Work 

• Design  an  efficient  hardware  implementa- 
tion for  a 4-processor  architecture 

• Use  verified  MiniCayuga’s  in  the  design 

• Verify  the  design 

• Reuse  MiniCayuga  verification  technology 

— A method  of  modeling  synchronous  hard- 
ware designs  in  the  Clio  verification  sys- 
tem 

- Formalizing  a class  of  properties  most 
commonly  encountered  in  verifying  de- 
signs 

- A “standard”  proof  strategy 
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Presentation  Outline 


• ic  circuit  design 


• The  computer-aided  hardware  verification 
tool 


• How  we  verified  it 


General  observations  about  the  effort 


The  Hardware  Design:  Overview 


Two  new  instructions: 


ICOP  REG  - initiates  and  co-orinates 

IC  computation 

MOVE  SREG  REG  - moves  special  REG  to 

general  REG 


I | check  if  voter  is  free 
Notfree  MOVE  STATUS  REG1 

JIF  REG1  Notfree 
ICOP  REG2 

I | check  if  IC  computation  is  complete 
Notready  MOVE  STATUS  REG1 

JIF  REG1  Notready 

I | move  the  results  of  IC  to  general  registers 

MOVE  SREGO  REG 3 
MOVE  SREG1  REG4 
MOVE  SREG2  REG5 
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The  Hardware  Design:  Overview 


Fault  Region  4 


Fault  Region  3 


voter  separate  from  processor:  modularity 


point-to-point  connection:  electrical  iso- 
lation 


serialize  data  transfers:  number  of  pins 
Vs.  time 


Fault  region:  processor,  voter,  and  the 

connections  they  feed 


no  absolute  indexing  scheme  for  proces- 


sors/voters 

- relative  indexing  scheme. 


succ,  succ2 , 


Slice ^ 


- IC  vectors  will  be  stored  in  the  proces- 
sors in  the  order  of  their  successors 


• Underlying  assumption:  clocks  are  syn- 

chronized with  at  most  a bounded  skew 

- hold  sender’s  signal  stable  for  one  phase 
longer  than  needed 
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^ System  Design  Behavior 


• Initiate.  draw  the  attention  of  voter  (l) 

• Load : transfer  private  values  (2) 

• Exchange:  exchange  received  values  (6) 

• Compute : compute  and  store  IC  vector  (3) 
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Controller  Slate  Machine 


MiniCayuga  Processor:  Summary 

• Inspired  by  Cayuga  (Cornell  University) 

• 32-bit  RISC  processor 

• Design  characteristics 

— 32  general  purpose  registers 

— small  and  simple  instruction  set 

— 3-stage  instruction  pipeline:  fetch,  com- 
pute, writeback 

— delayed  jump,  pipeline  stalling,  internal 
forwarding 

— interrupt 
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What  do  we  prove  ? 


Assuming 

• every  Cayuga-FT  is  about  to  execute  an 
ICOP, 

• every  Voter  is  ready  to  vote,  and 


• there  is  at  most  one  faulty  region, 


then,  12  cycles  later  the  system  state  will  sat- 
isfy the  following  conditions: 

• The  IC  vectors  in  the  processors  are  iden- 
tical “up  to  rotation.” 

• The  IC  vectors  are  correct  w.r.t.  to  the 
processor  private  values  12  cycles  earlier. 
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A Computer-Aided  Verification  Tool 

• Specializes  Clio  to  the  domain  of  finite 
state  controller  systems 

• Design  specification  generation 

• Verification  condition  formulation 

• Automatic  proof  support 
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Finite  State  Controller  Systems  (FSCS) 

• Central  Controller  + Data  Path  compo- 
nents 


• Component  behavior  is  specified  as  a set 
of  actions 

• Controller  is  specified  as  an  FSM  which 
schedules  a set  of  actions  on  the  compo- 
nents. 

• Timing  Model 

- Every  transition  corresponds  to  a clock 
cycle  (with  multiple  phases) 

— An  action  may  have  zero  or  more  units 
(phases)  of  delay 

— Actions  are  synchronized  with  state  tran- 
sitions 
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Specification  technology  reused 


• a method  of  formalizing  the  intended  op- 
erational model  of  an  FSCS  in  Caliban/Clio 


designspecgen  : : 

data-path-structure  -> 

controller-structure  -> 

controller-schedule  -> 

actions-behavior  ->  design-spec 


Execute  *.  : STATE  > STATE 

"single  clock  cycle  behavior  of  design” 
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Proof  technology  shared 

• Form  of  the  most  commonly  proved  con- 
ditions 

— Invariant  conditions 


— Advance  conditions 


Avb6 


Pr 


Proof  strategy: 


I 4 


rontrolled  symbolic  eval- 


uation (rewriting)  with  selective  case-splits” 
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The  Specification  Hierarchy 


Rationale  for  the  hierarchy 


• Decompose  proofs  into  manageable  units 

• Need  for  the  black  level 

- introduce  “error"  actions 

— type  of  Execute  is  different  from  that 
Of  action 

• Implication  of  intermediate  levels 

- pro : proof  can  take  “bigger"  steps 

— con : must  come  up  with  intermediate 
abstract  specification 
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Top  Level  Specification 


| | IcNetState  «(INDEX  ->  FTCstate)  , 

| | (INDEX  ->  Voterstate)  , Interrupts» 

IcNetStep  «ftc,vtr,  int:rest»  = 

«newftc ,newvtr  ,rest>> 
where  newftc  index 

= fault _ftc_step  index  ftc  (ftcinput  index) 
newvtr  index 

= fault _vtr_step  index  vtr  (vtrinput  index) 
ftcinput  index 

= make_ftc_in  (select.int  index  int) 

(fault _to_proc  index  ftc  vtr) 

vtrinput  index 

= Voterinput  index  ftc  vtr 

(ftcinput  index  ) 


fault _ftc_step  index  s in  = 

FtCayugaStep  (s  index)  in  , "(faulty  index) 
byzCayugaStep  (s  index)  in 

f ault_vtr_step  index  s = 

voterstep  (s  index)  , "(faulty  index) 
byzstep  (s  index) 
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Formal  Statement  of  Correctness 


MainTheorem  : = 

Preconditions  's'  =>  ResultConsistent  's' 

ResultConsistent  's'  := 

Consistent  ‘icvec  s (Iterate  #12  IcNetStep  s) ' 

Consistent  ' array ' := 

'faulty  index'= ‘False ' => 

IndexConsistent  ' array ' 'index' 


IndexConsistent  'array'  'index'  := 

('faulty  (succ  index) '= 'False '=> 

'(array  index) . succ '=' array  (succ  index)') 

& ('faulty  (succ2  index) '= 'False '=> 

'(array  index) . succ2 '= 'array  (succ2  index)') 

& ('faulty  (succ3  index) '= 'False '=> 

'(array  index) . succ3'= 'array  (succ3  index)') 
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Preconditions  's' 

Proper_icnet  ‘s'  & Sync  ‘LDP1  s 


All.go  ‘s' 


Sync  'cs'  ‘ «f  tc , vtr , inlist»  ‘ : = 

(‘faulty  ONE'  = 'False'  => 

‘control  (vtr  0NE)'=  cs  ) 

& (‘faulty  TWO'  = 'False'  => 

‘control  (vtr  TW0)‘=‘cs  ) 

& (‘faulty  THREE'  = 'False'  => 

‘control  (vtr  THREE) '=  cs  ) 

& (‘faulty  FOUR'  = 'False'  «> 

‘control  (vtr  F0UR)‘x‘cs  ) 


All.go  's'  := 

(‘faulty  0NE‘='False‘  => 

(‘go.of  (vtr  s ONE) '= 'False'  & 

& (‘faulty  TWO' = 'False'  => 

( ‘ go_of  (vtr  s TWO) '= 'False'  & 
& (‘faulty  THREE' = 'False'  => 

(‘go_of  (vtr  s THREE) '= 'False' 
& (‘faulty  FOUR‘=‘False'  => 

(‘go.of  (vtr  s FOUR) ‘“'False' 


‘go_signal  s 0NE'=‘ 
‘go_signal  s TW0‘=‘ 
& ‘go_signal  s THRE 
& ‘go.signal  s FOUR' 
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Preconditions  's'  := 

Proper_icnet  's'  k Sync  'LDP1*  ' s'  k All_go  's 


Sync  ‘ cs ' ' «ftc , vtr , inlist»  * : = 

( ‘faulty  ONE*  = ‘False*  => 

‘control  (vtr  0NE)‘=‘cs‘) 
k (‘faulty  TWO*  = ‘False*  => 

‘control  (vtr  TW0)‘=‘cs‘) 
k (‘faulty  THREE*  = ‘False*  => 

‘control  (vtr  THREE) ' = ' cs ' ) 
k (‘faulty  FOUR*  = ‘False*  => 

‘control  (vtr  F0UR)‘=‘cs‘) 


All_go  ‘s*  := 

(‘faulty  ONE *= ‘False*  => 

(*go_of  (vtr  s ONE) * = ‘False * k *go_signal  s ONE * = ‘GO*)) 
k (‘faulty  TWO *= ‘False*  => 

(*go_of  (vtr  s TWO) *= ‘False*  k ‘go.signal  s TW0'='G0')) 

k (‘faulty  THREE *= ‘False*  => 

('go.of  (vtr  s THREE) *= ‘False* 

& ‘go.signal  s THREE ‘ = ‘ GO ‘ ) ) 


k (‘faulty  FOUR *= ‘False*  => 

('go_of  (vtr  s FOUR) *= ‘False* 

k *go_signal  s FOUR' -' GO')) 
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The  proof  strategy  reused 

“controlled  symbolic  execution  of  design" 


l instantiate  the  states  of  components  and 
inputs  with  appropriate  symbolic  constants. 

2.  Add  all  the  conditions  on  the  constants 
implied  by  the  preconditions  of  the  theo- 
rem as  hypothesis. 

3.  Symbolically  evaluate  design. 

4.  Try  case-splitting  on  all  the  conditionals 
automatically. 

5.  If  either  of  the  previous  two  steps  seem  to 
take  too  long,  then  case-spilt  on  the  con- 
troller states  and  inputs  before  symbolic 
evaluation  (step  3). 
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New  technology  needed 


• Modeling  faulty  behavior 

• Specification 

- determining  the  right  hierarchy 

- writing  intermediate  “abstract”  spec 

- defining  abstraction  function  (ABS) 

• Proof:  "design  level  properness”  implies 
"abstract  level  properness" 
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General  Observations 


• An  engineering-oriented  verification  expe 
rience 

Lilith  — *■  MiniCayuga  — ► IC  circuit 

• Methodology:  top-down  + bottom-up 

• Level  of  effort:  1 man  year 

— building  the  tool 

— developing  designs 

— verification 
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Verification  Effort  Milestones 

• formulated  a top  level  correctness  state- 
ment 

• designed  and  verified  a simple  voter  circuit 


• specified  voter  and  processor  for  a contin- 
uous voting  scheme 

• designed  and  verified  second  voter  design 
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• discovered  continuous  voting  scheme  was 
“hard  to  synchronize” 

• respecified  voter  and  processor  for  a voting- 
on-demand  scheme 

• redesign  and  reverify  voter 

• verified  overall  system 

• verified  processor 
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• To  integrate  theorem  proving  based  verifi 
cation  technology  into  the  design  process 

we  need: 

— more  machine  assistance 

— domain  specialization 


• The  next  step  ? 

— A useful  way  of  reporting  failed  proof 
attempts 

- Interaction  with  motivated  and  patient 
engineering  design  teams  and  projects 
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Talk  Topics 

• Hardware  Verification:  What  Is  It? 

• Formal  Methods:  What  Good  Are  They? 

• Verification  Methodology 

• Present  Accomplishments 

• Expected  Near  Term  Results 

• Present  Trends 

• Future  Directions 

• Collaborations  and  Technology  Transfer 

• Technology  Enablers 

• Conclusions 
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Hardware  Verification:  What  Is  It? 

The  mathematical  formalization  of  the  specification  of 
any  (all)  aspects  of  hardware  design. 

We  specifically  are  interested  in  the  design  of 
hardware  for  digital  computing. 

Goals: 

• Completely  replace  programmer’s  manuals, 
timing  diagrams,  interface  specifications, 
power  requirements,  etc.  with  clear  precise 
formulas. 

• Provide  a perfectly  clear  foundation  upon 
which  systems  can  be  built. 


V J 
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Formal  Methods:  What  Good  Are  They? 

Formal  methods  in  the  U.S.  have  a bad  credit  rating. 

Over  the  years,  good  mechanized  software 
verification  systems  have  been  constructed. 

Good  software  verification  tools  are  being  extended  to 
include  hardware  verification,  thus  providing  good 
systems  verification  tools. 

Hardware  verification  seems  more  tractable  than 
software  verification: 

• few,  repeatedly-used,  low-level  constructs; 

• specification  domain  is  less  abstract  (fairly 
concrete);  and 

• formal  methods  can  be  used  incrementally. 

Last  point  is  critical,  note  Bryant’s  work. 
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Our  Verification  Methodology 

We  employ  the  Boyer-Moore  logic  to: 

• write  design  specifications; 

• write  behavioral  specifications;  and 

• record  relations. 

The  Boyer-Moore  theorem  prover 

• insures  that  definitions  are  well  formed; 

• checks  that  proofs  are  correct;  and 

• manages  our  evolving  database  of  facts. 
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Present  Accomplishments 

Our  application  of  formal  methods  to  hardware 
specification  and  verification  include: 

• Core  RISC  specification; 

• FM8502  microprocessor  verification; 

• verification  of  circuits  using  standard  TTL 
components; 

• a formalization  of  a simple  HDL;  and 

• verified  synthesis  of  combinational  circuits. 

Let  us  consider  several  in  more  detail. 


Core  RISC 

m Rwier  has  formally  specified  a set  of  instructions 
wTaSS  a Core  RISC-complienI  processor. 
This  formalization  includes. 

. byte,  half-word,  and  long-word  memory  accesses; 

. Boolean,  natural  number,  and  integer  ALU 
operations; 

• a minimum  register  set;  and 

• an  exception  mechanism. 

The  emphasis  here  has  been  on  mathmatically 
modeling  the  instruction  set. 

Our  study  of  RISC  architectures  indicates  that  we 
need  to  be  able  to  model  multi-phase  caking 
«;rhemes  before  we  attempt  to  design  a build  a 
verified  Core  RISC  processor.  This  effort  is  ongoing. 


The  FM8502  Fabrication 

Currently,  our  primary  effort  involves  the  fabrication  of 
the  FM8502  microprocessor. 

This  fabrication  effort  is  a test-of-concept;  that  is  can 
we  manufacture  formally  modeled  circuits  and  qet 
them  working? 

The  FM8502  microprocessor  is  a 32-bit  general 
purpose  microprocessor  with: 

• 32-bit  addressing; 

• 1 6 general-purpose  registers; 

• two-address  architecture; 

• 5 addressing  modes; 

• a 16-function  ALU 

• extensive  flag  support;  and 

• little  else. 
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The  FM8502  Implementation 
Specification 


To  be  able  to  manufacture  the  FM8502  with  some 
precision,  we  have  been  working  on  the  formalization 
of  an  HDL. 

We  will  prove  the  correctness  of  our  HDL  description 
of  the  FM8502,  and  then  translate  our  HDL 
description  into  a commercial  HDL. 

Our  HDL  provides  our  lowest-level  model  for  the 
FM8502  implementation: 

• every  internal  gate  and  register  is  described; 

• every  I/O  pad  is  defined;  and 

• we  expect  to  validate  our  test  vectors  directly  on 
our  HDL  description. 

Our  HDL  specification  also  includes  all  of  the  internal 
test  logic. 
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The  FM8502  Pinout 

• I /-Vianram  of  the  FM8502  pinout. 
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A Formal  HDL 


Our  HDL  is  structured  like  commercial  HDL’s: 

• netlist  based; 

• heirarchicaly  structured; 

• occurence-oriented;  and 

• allows  multiple  views  of  circuits. 

We  have  a formal  specification  of  our  HDL: 

• a predicate  recognizes  well-formed  circuits-  and 

• several  interpreters  define  the  semantics.  ’ 
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HDL  Examples  of  Circuits 


7 (HALF -ADDER  (A  B) 

(SUM  CARRY) 

((  GO (SUM)  B-XOR(A  B) ) 

( G1 (CARRY)  B-AND (A  B) ) ) ) 


CARRY 


The  following  full-adder  specification  refers  twice  to 
the  half-adder  specification  above. 

' (FULL-ADDER  (ABC) 

(SUM  CARRY) 

((  TO (SUMl  CARRY1)  HALF -ADDER (A  B) ) 

( Tl (SUM  CARRY2)  HALF-ADDER ( SUMl  C) ) 

( T2 (CARRY)  B-OR (CARRYl  CARRY2) ) ) ) 


CARRY 
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Verified  Synthesis 

We  perform  synthesis  by 

• writing  circuit  generator  programs, 

• verifying  the  circuit  generator  programs,  and 

• then  running  the  generators  to  produce  provably 
correct  circuits. 

In  other  words,  after  a circuit  has  been  generated  we 
need  not  inspect  it  for  the  Boolean  correctness. 
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An  ALU  Generator 


We  have  an  arbitrary  size,  1 6-function  ALL)  generator 
which  is: 

• programmable  --  ALUs  with  different  internal 
structure  can  be  produced; 

• "intelligent"  - internal  buffers  are  only  added  when 
needed;  and 

• has  been  verified  to  generate  correct  n-bit,  gate- 
level  ALU  descriptions. 

Simple  translators  can  convert  the  ALU  descriptions 
into  conventional  CAD  languages  (e.g.,  VHDL). 

To  replay  the  proof  only  takes  about  20  (Sun  3) 
minutes. 


v > 
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ALU  Generator  Output  Summary 


r 


Summarized  below  are  some  characteristics  of  the 
ALUs  generated  by  our  verified  ALU  generator. 


ALU  Characteristics 

Size 

Gate  Count 

Fanout 

Delay 

1 bit 

126 

8 

12 

2 bits 

149 

8 

14 

4 bits 

196 

8 

17 

8 bits 

297 

8 

22 

1 6 bits 

491 

8 

26 

32  bits 

880 

8 

30 

64  bits 

1665 

8 

35 

1 28  bits 

3227 

8 

39 

Payoff:  It  only  takes  0.6  seconds  to  generate  a 
correct  32-bit  ALU,  1 .3  seconds  for  a 64-bit  ALU,  and 
3.1  seconds  for  a 128-bit  ALU. 

I ) 
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Expected  Near  Term  Results 

Several  projects  underway  which  will  conclude  this 
year  are: 

• an  ability  to  verify  sequential  circuits  generators; 
and 

• the  fabrication  of  the  FM8502  microprocessor. 

We  are  using  both  combinational  and  sequential  logic 
synthesis  techniques  in  the  fabrication  of  the  FM8502. 

We  will  be  able  to  generate  a correct  n-bit 
microprocessor  (so  long  as  the  word  size  is  large 
enough  to  contain  FM8502  instructions.) 

We  will  generate  a gate-array  specification  directly. 

We  are  generating  our  test-vectors  directly  from  our 
formal  circuit  specifications. 
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Present  T rends 

There  is  increasing  interest  in: 

• boolean  comparison  --  which  should  lead  the  way 
to  more  general  purpose  techniques; 

• register-transfer  specifications  with  circuit 
verification; 

• formalization  of  self-timed  circuits; 

• formalization  of  timing  behavior;  and 

• transformational  systems. 

These  trends  are  all  indicative  of  increased  use  of 
formal  techniques  for  hardware  specification  and 
verification. 

And  these  techniques  are  being  applied 
incrementally. 
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Future  Directions 


In  the  future  we  hope  to: 

• formalize  a subset  of  VHDL  (using  our  Ada 
formalization  experience); 

• perform  tool  verification  (e.g.,  logic  minimizer, 
tautology  checkers); 

• verify  a Core  RISC  microprocessor  with  memory 
management;  and 

• continue  our  work  on  formalizing  hardware 
interfacing  and  use  specifications. 

This  last  item  is  hardest  and  has  the  biggest  payoff. 
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Industrial  Collaborations 


r 


We  have  been  working  with  DEC  for  two  years. 

Motorola  may  attempt  the  specification  (and  possibly 
the  verification)  of  one  of  their  microcontrollers. 

Technology  Transfer 

We  highly  value  interactions  with  industry;  we  all 
profit. 

Our  formal  techniques  may  be  used  incrementally, 
i.e.,  "creeping  formalization." 

Industry  first  employs  our  techniques  for 
(unambiguous)  specification,  later  for  verification. 

Specification  is  a big  problem  for  industry  --  formal 
specification  allows  analysis  without  exhaustive 
testing. 

J 
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Technology  Enablers 

Is  the  state-of-the-art  separating  further  from  the 
state-of-the-practice? 

To  enable  the  use  of  formal  techniques  in  hardware 
design  we  need  to: 

• train  more  engineers  with  formal  methods  (not  train 
mathematicians  to  be  engineers); 

• make  existing  tools  and  techniques  more 
accessible  to  engineers;  and 

• make  formal  techniques  the  most  economical 
method  of  hardware  validation. 

A big  success  or  two  would  help  us  get  industry’s 
attention. 
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Conclusions 


Formal  methods  can  be  used  to  provide  accurate 
specifications. 

Hardware  verification  provides  increased  assurance 
of  circuit  correctness. 

Formal  techniques  provide  a good  growth  path;  they 
scale  up  well. 

The  credit  rating  of  formal  techniques  is  improving. 

Goals: 

• Completely  replace  programmer’s  manuals, 
timing  diagrams,  interface  specifications, 
power  requirements,  etc.  with  clear  precise 
formulas. 

• Provide  a perfectly  clear  foundation  upon 
which  systems  can  be  built. 
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Microprocessor  Verification 


VIPER,  the  first  commercially  available, 
“verified"  microprocessor,  has  never  been 
formally  verified. 


The  proof  was  not  completed  even  though 
2 years  were  spent  on  the  verification. 


Microprocessor  Verification 

(continued) 


Our  research  is  aimed  at  making  the  verifi- 
cation of  large  microprocessors  tractable. 


Our  objective  is  to  provide  a framework  in 
which  a masters-level  student  can  verify 
VIPER  in  6 person-months. 


Determining  Correctness 


In  VIPER  (and  most  other  microprocessors), 
the  correctness  theorem  was  shown  by  proving 
that  the  electronic  block  model  implies  the 
macro-level  specification. 


Macro  Level 
Interpreter 


Electronic  Block 
Model 
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The  Problem 

(continued) 


• Microprocessor  verification  is  done  through  case  analysis  on  the  in- 
structions in  the  macro  level. 

• The  goal  is  to  show  that  when  the  conditions  for  an  instruction’s 
selection  are  right,  the  electronic  block  model  implies  that  it  operates 
correctly. 

• A lemma  that  the  EBM  correctly  implements  each  instruction  can  be 
used  to  prove  the  top-level  correctness  result. 


6 


The  Problem 


Unfortunately,  the  one— step  method  doesn't 
scale  well  because 


• The  number  of  cases  gets  large. 

• The  description  of  the  electronic  block 
model  is  very  large. 
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Hierarchical  Decomposition 


• A microprocessor  specification  can  be  de- 
composed hierarchically. 


• The  abstract  levels  are  represented  explic- 
itly. 
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Interpreters 


ological  a 


pproach  to  microprocessor  verification. 


The 


model  drives  the  specification. 


• The 


model  drives  the  verification. 
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Interpreters 

(top  level) 


NOT  filmed 
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Specifying  an  Interpreter 

(overview) 


We  specify  an  interpreter  by: 

• Choosing  a n-tuple  to  represent  the  state, 

S. 

• Defining  a set  of  functions  denoting  indi- 
vidual interpreter  instructions,  J. 

• Defining  a next  state  function,  N. 

• Defining  a predicate  denoting  the  behavior 
of  the  interpreter,  I. 
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Verifying  an  Interpreter 

(overview) 


We  verify  an  interpreter,  I with  respect  to  its 
implementation  M by  showing 

M =$»  I. 

To  do  this,  we  will  show  that  every  instruction 
in  J can  be  correctly  implemented  by  M: 

Vj  € J. 

M =$■  (Vt:time. 

C(t)  =>•  s(t  + n)  = i(s(f))) 

where  C represents  the  conditions  for  instruc- 
tion j’s  selection. 
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AVM-1 


We  have  designed  and  are  verifying  a micro 
computer  with  interrupts,  supervisory  modes 
and  support  for  asynchronous  memory. 


• The  datapath  is  loosely  based  on  the  AMD 
2903  bit-sliced  datapath. 

• The  instruction  format  is  very  simple. 


• The  control  unit  is  microprogrammed. 

/ 
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AVM-1  's  Instruction  Set 

(subset) 


opcode 

Mnemonic 

Operation 

000000 

Jmp 

jump  on  16  conditions 

UUUUUl 

CALL 

can  subroutine 

000010 

^INT 

user  interrupt  

000110 

LD 

load  " 

000111 
A “1  A A A A 

ST  | 

t"  store  ~ — 

010000 
A H H A <4  a* 

ADD 

add  (3-operands) 

011011 
— rrrrrn — 

SUBI 

subtract  immediate  (2-operands) 

011111 

NOOP 

no  operation 

• The  architecture  is  load-store. 


• The  instruction  set  is  RISC-like. 


• There  is  a large  register  file. 
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The  Phase-Level  Specification 


The  n-tuple  representing  the  state: 


Sphase  = ( mir,mpc,reg , 

alatch , blatch,  mar , mbr , 
elk , mem , urom , ireg,  lack) 
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The  Phase-Level  Specification 


A typical  function  specifying  an  instruction’s 
behavior  from  J phase'- 

h fjef  phase.two  rep  (mir,  mpc,  reg,  alatch,  blatch, 

mbr,  mar,  elk,  mem,  urom, 
ireq,  iack)  = 

(mir,  mpc,  reg, 

EL  (bt5_val  (SrcA  mir))  reg, 

EL  (bt5_val  (SrcB  mir))  reg, 

mbr,  mar,  (T,F) , mem,  urom,  ireq,  lack  mir) 
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The  Electronic  Block  Model 


The  electronic  block  model  is  not  specified  as 
an  interpreter. 


• EBM  is  a structural  specification. 

• The  specification 

— is  in  terms  of  smaller  blocks. 

— uses  existential  quantification  to  hide 
internal  lines. 
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Objects 


There  are  several  abstract  classes  of  objects 
that  we  will  use  to  define  and  verify  an  ab- 

i 

stract  interpreter. 


: estate  An  object  representing  system 
state. 

: *key  The  identifying  tokens  for  instruc- 
tions. 

: time  A stream  of  natural  numbers. 

We  will  prime  class  names  to  indicate  that  the 
objects  are  from  the  implementing  level. 
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Operations 


Operation 

Type 

instJist 

: ( *key  x ( estate  — > *state))list 

key 

: *key  — » num 

select 

: estate  — > *fcei/ 

cycles 

: *key  — * num 

substate 

Impl 

: (time  — > estate1 ) — > bool 

clock 

: estate'  — ► 

begin 

: *fce2/' 
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Interpreter  Theory 
(obligations) 


The  instruction  correctness  lem  m 3 is  impor- 
tant in  the  generic  interpreter  verification. 

Here  is  the  generic  version  of  that  lemma  for 
a single  instruction: 

i-def  INSTXORRECT  s'  inst  = 

(Impl  s')  =»- 
Vt7  : time'. 

let  s = (At.  substate(s' t'))  in 
let  c = (cycles(select(s  f ')))  in 
(select(s  t')  = (FST  inst))  a 
(clocks'  t')  = begin)  =» 

((SND  inst)  ( s t')  = ( s(t ' + c)))  A 
(clock(s,(t/  + c))  = begin) 
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Interpreter  Theory 

(obligations) 


Using  the  predicate  INST_CORRECT,  we  can 
define  the  theory  obligations: 

1.  The  instruction  correctness  lemma: 

EVERY  (INST_CORRECT  s')  instJist 

2.  Every  key  selects  an  instruction: 

V&  : *key.  (key  k)  < (LENGTH  instJist) 

3.  The  instruction  list  is  ordered  correctly: 

Vfc  : *key.  k = (FST  (EL  (key  k)  instJist)) 
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Instantiation 


Generic 
Interpreter 


Macro  Level 
Definitions. 


Macro  Level 
Interpreter 


Generic 
Interpreter 


/''Micro  LeveTN 
V^Defin  i tions^/ 


Micro  Level 
Interpreter 


Generic 
Interpreter 


Phase  Level 
Definitions. 


Phase  Level 
Interpreter 


Electronic  Block 
Model 


PRECEDING  PAGE  BLANK  NOT  FILMED 


57 


Interpreter  Theory 

(temporal  abstraction) 


We  need  to  show  a relationship  between  the 
state  stream  at  the  implementation  level  and 
the  state  stream  at  the  top  level. 


tl  <2  *3  ^4  ^5 

o o o o o 


oooooooooo 


tf  fl  ff  ft  4.1  4.1  4.1  4.1  J.I  + 1 

Z1  z2  z3  z4  z5  z6  z7  z8  z9  r10 

The  function  / is  a temporal  abstraction  func- 
tion for  streams. 


l 
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Interpreter  Theory 

(definition) 


An  interpreter's  behavior  is  specified  as  a pred- 
icate over  a state  stream. 


I ~ def  INTERP  s — 

Vt  : time. 

let  n = (key(select(s  t)))  in 

s(t  + 1)  = (SND  (EL  n instJist))(s  t ) 


69 


PRECEDING  PAGE  BLANK  NOT  FILMED 


Interpreter  Theory 

(correctness  result) 


Our  goal  is  to  verify  an  interpreter,  I with 
respect  to  its  implementation  M by  showing 

M =*I. 

Here  is  the  abstract  result: 

h Impl  s'  A (clocks'  0)  = begin)  =>• 
INTERP  (so/) 

where 

s = (At : time.  substate(s/ 1))  and 
/ = (time_abs  (cycles  oselect)s) 
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Instantiating  a Theory 

Instantiating  the  abstract  interpreter  theory 
requires: 

• Defining  the  abstract  constants. 

• Proving  the  theory  obligations. 

• Running  a tool  in  the  formal  theorem  prover. 
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Definitions 


We  wish  to  instantiate  the  abstract  interpreter 
theory  for  the  phase-level.  The  electronic 
block  model  will  be  the  implementing  level. 


Operation 

Instantiation 

instJist 

a list  of  instructions 

key 

bt2_val 

select 

GetPhaseClock 

cycles 

Phase  Le  ve  1 Cy  c 1 es 

substate 

PhaseSubstate 

Impl 

EBM 

clock 

GetEBMCIock 

begin 

EBM_Start 
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An  Example 


After  proving  the  theory  obligations,  we  can  perform 
the  instantiation. 

let  theorem_list  = 

instant  iate.abstract  .theorems 
’ gen.I ’ 

[Phas  e _ I .EVERY .LEMMA ; 

Phase.I.LENGTH.LEMMA ; 

Phas  e _ I _KE Y.LEMMA] 

[ 

" ( C(F,F) ,phase_one; 

(F,T) ,phase_two 
(T,F) ,phase_three 
(T,T) ,phase.four] , 
bt2.val,  GetPhaseClock , 

PhaseLevelCycles , PhaseSubstate , 

EBM,  GetEBMClock,  EBM.Start)"; 

"(A  t:time.  (mir  t,  mpc  t,  reg.list  t, 

alatch  t,  blatch  t, 
mbr.reg  t,  mar.reg  t, 
elk  t,  mem  t,  urom))" 

] 

» PHASE ’ ; ; 
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The  Electronic  Block  Model 


h EBM  rep  (A  t.  (mir  t,  mpc  t,  reg  t,  alatch  t,  blatch  t, 

mbr  t,  mar  t,  elk  t,  mem  t , urom, 
ireq  t,  iack  t))  = 

3 opc  ie_s  sm_s  iack_s 

amux_s  alu_s  sh_s  mbr_s  max_s  rd_s  wr_s 

cselect  bselect  aselect 

neg_f  zero_f  (f loat :time->bool) . 

DATAPATH  rep  amux_s  alu_s  sh_s  mbr_s  mar_s  rd_s  vr_s 
cselect  bselect  aselect  neg_f  zero_f  float 
float  ireq  iack_s  iack  opc  ie_s  sm_s 
elk  mem  reg  alatch  blatch  mar.reg 
mbr_reg  reset_e  ireq_e  A 

C0NTR0L_UNIT  rep  mpc  mir  elk  amux_s  alu_s  sh_s  mbr_s 

mar_s  rd_s  vr_s  cselect  bselect  aselect  neg_f 
zero_f  ireq  iack_s  opc  ie_s  sm_s  urom 
reset_e  ireq_e 


Fully  expanded,  the  electronic  block  model 
specification  fills  about  six  pages. 
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Future  Work 


• New  architectural  features. 


• Composing  verified  blocks. 


• Verifying  operating  systems. 


• Gate-level  verification. 


• Byte-code  interpreter  verification. 


• Other  classes  of  computer  systems. 


An  Example 

(continued) 


After  some  minor  manipulation,  the  final  result  be- 
comes: 

I-  EBM 

(A  t. 

(mir  t,mpc  t,reg_list  t,alatch  t,blatch  t, 
mbr_reg  t,mar_reg  t,  elk  t,mem  t,urom))  ==> 
Phase_I 
(At. 

(mir  t,mpc  t,reg_list  t,alatch  t,blatch  t, 
mbr_reg  t,mar_reg  t,  elk  t,mem  t,urom)) 
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Conclusions 


The  generic  proof 

• Cleared  away  all  the  irrelevant  detail. 

• Formalized  the  notion  of  interpreter  proofs 
which  has  been  used  in  several  micropro- 
cessor verifications. 

• Provided  a structure  for  future  micropro- 
cessor verifications. 
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The  VIPER  project  has  so  far  produced  a formal  specification  of  a 32  bit 
RISC  microprocessor,  an  implementation  of  that  chip  in  radiation-hard  SOS 
technology,  a partial  proof  of  correctness  of  the  implementation  which  is 
still  being  extended,  and  a large  body  of  supporting  software.  The  time 
has  now  come  to  consider  what  has  been  achieved  and  what  directions  should 
be  pursued  in  future . 

The  most  obvious  lesson  from  the  VIPER  project  has  been  the  time  and  effort 
needed  to  use  formal  methods  properly.  Most  of  the  problems  arose  in  the 
interfaces  between  different  formalisms  e.g.  between  the  (informal)  English 
description  and  the  HOL  spec,  between  the  block-level  spec  in  HOL  and  the 
equivalent  in  ELLA  needed  by  the  low-level  CAD  tools.  These  interfaces 
need  to  be  made  rigorous  or  (better)  eliminated. 

VIPER  1A  (the  latest  chip)  is  designed  to  operate  in  pairs,  to  give 
protection  against  breakdowns  in  service  as  well  as  design  faults.  We  have 
come  to  regard  redundancy  and  formal  design  methods  as  complementary,  the 
one  to  guard  against  normal  component  failures  and  the  other  to  provide 
insurance  against  the  risk  of  the  common-cause  failures  which  bedevil 
reliability  predictions . 

Any  future  VIPER  chips  will  certainly  need  improved  performance  to  keep  up 
with  increasingly  demanding  applications.  We  have  a prototype  design  (not 
yet  specified  formally)  which  includes  32  and  64  bit  multiply,  instruction 
Pr©“f®tch,  more  efficient  interface  timing,  and  a new  instruction  to  allow 
a quick  response  to  peripheral  requests.  Work  is  under  way  to  specify  this 
device  in  MIRANDA,  and  then  to  refine  the  spec  into  a block- level  design  by 
top-down  transformations.  When  the  refinement  is  complete,  a relatively 
simple  proof  checker  should  be  able  to  demonstrate  its  correctness. 


Example  of  NODEN  output 

The  NODEN  analysis  suite  provides  automatic  com- 
parison between  the  specification  and  design  of  moder- 
ately complex  blocks  of  logic.  The  following  example 
is  taken  from  the  VIPER  design.  MINOR  is  the  sim- 
plest block  in  the  chip,  essentially  consisting  of  a three 
bit  counter.  Following  this  paragraph  is  its  specification 
in  NODEN-HDL,  whilst  on  the  following  pages  are  a cor- 
root  and  incorrect  implementation.  The  final  page  shows 
the  output  of  the  comparison  program  when  presented 
with  the  erroneous  circuit. 


\ **  MINOR  STATE  LOGIC  in  NODEN  **  \ 


FN  INCW0RD3  * (word3:  minor)  ->  word3: 
IF  (VAL3  minor)  * 7 
THEN  W0RD3  0 

ELSE  W0RD3((VAL3  minor) +1) 

FI. 


BLOCK  MINOR  = (bool:  nextmainbar  advance 

reset  intresetbar) 
->  (~word3:  minor): 

IF  reset  OR  (NOT  intresetbar)  OR 
(advance  AND  (NOT  nextmainbar)) 

THEN  W0RD3  0 
ELIF  advance 

THEN  INCW0RD3  minor 
ELSE  minor 
FI. 
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\ **** 


functions  ****  \ 


’Library’  of  primitive  gate 


FN  INV  “(bool:  a > 
FN  NAND2-(bool:  a b ) 
FN  EXNOR® (bool : a b ) 
FN  ORNAND=(bool : abed) 


->  bool:  NOT  a. 

->  bool:  NAND(a.b). 

->  bool:  a “ b. 

->  bool:  NAND(a  OR  b.c  OR  d) . 


\ NB.  NAND3  ft  NAND4  are  built-in  functions  \ 


\ ****  Correct  gate  level  implementation  **** 

BLOCK  MINOR  = (bool:  nextmnbar  advance  reset 
->  (■'word3:  minor)  . 


BEGIN 

LET  qbar.l  :-  NOT  (minorllJ), 
qbar_2  :-  NOT  (minor [2]). 
qbar_3  : = NOT  (minor [3]) • 


LET  gb2 
LET  gb4 
LET  gbl 
LET  gb3 
LET  gb7 
LET  gb8 
LET  gbll 
LET  gbl 2 
LET  gbl 3 


s INV (advance)  . 

= INV(reset)  . 

= NAND4 (nextmnbar . advance , gb4 , intr stbar 
= NAND3(gb2 , gb4,  intrstbar) . 

:=  INV(qbar_l) . 

= EXNOR(qbar_l , qbar_2) . 

= INV (qbar_2) . 

= NAND2(gb7 , gbll). 

= EXN0R(gbl2,  qbar_3) . 


OUTPUT  (0RNAND(gb7 , gbl,  gb3,  qbar.l) , 

0RNAND(gb8 , gbl.  gb3 , qbar_2) , 

ORNAND (gbl3 , gbl,  gb3,  qbar_3) 

) 

END. 
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\ **♦*  Wrong  gate  level  implementation  ****  \ 

BLOCK  M.ERR  - (bool:  nextmnbar  advance  reset  intrstbar) 
->  (~word3 : minor): 

BEGIN 

LET  qbar_l  NOT  (minor[l]>, 

qbar_2  NOT  (minor [2]), 

qbar_3  :=  NOT  (minor [3]). 

LET  gb2  : = INV(advance) . 

LET  gb4  : = INV (reset) . 

LET  gbl  NAND4 (nextmnbar .advance, gb4, intrstbar) 

LET  gb3  NAND3(gb2 , gb4,  intrstbar). 

LET  gb7  INV(qbar_l) . 

\ **  Inverted  qbar_2  **  \ 

LET  gb8  :*  EXNOR(qbar_l , NOT  qbar_2) . 

LET  gbll  :*  INV (qbar_2) . 

\ **  Missing  NAND  with  gb7  +*  \ 

LET  gbl2  gbll. 

LET  gbl3  :=  EXN0R(gbl2,  qbar_3) . 

\ **  Inverted  first  output  **  \ 

OUTPUT  (N0T(0RNAND(gb7 , gbl,  gb3,  qbar_l)) . 

0RNAND(gb8 , gbl,  gb3,  qbar_2) , 
0RNAND(gbl3 , gbl.  gb3,  qbar_3) 

) 

END. 
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PRECEDiNG  PAGE  BLANK  NOT  FILMED 


Specification:  ’MINOR’  Implementation:  ’M_ERR ’ 

COMPARISON  ERROR:  Implementation  output  ’minor [1] ’ 
is  always  incompatible  with  the  specification  of 
’minor  [1]  ’ output  inverted? 

COMPARISON  ERROR:  Implementation  output  ’minor [2] ’ 
is  incompatible  with  the  specification  of  ’minor [2] 
under  the  following  circumstances : - 

nextmainbar  = t 
advance  = t 
reset  = f 
intresetbar  = t 

For  specification  output  ’minor [3] ’ - implementation 
output  ’minor [3]  ’ 

WARNING:  Specification  depends  on  minor[l]  and 
implementation  doesn’t 

COMPARISON  ERROR:  Implementation  output  ’minor [3] ’ 
is  incompatible  with  the  specification  of  ’minor [3] 
under  the  following  circumstances : - 

nextmainbar  **  t 
advance  * t 
reset  = f 
intresetbar  = t 
minor [2]  = f 

**♦  Comparison  fails,  invalid  implementation  *** 
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NODEN  changes 


Negative  integer  subranges  allowed 
E.g.  TYPE  i8  = INT[-128..127]. 

Automatic  casts  between  types 
E.g.  (t,t,f)  + bool3_val  + i8_val 

2’s  compliment  []bool  to  integer  ops 


Explicit  legal  value,  Ibool 


Compiler  about  four  times  faster. 


Analyer  about  twice  as  fast. 


PRECEDING  PAGE  BLANK  NOT  FILMED 


+ 


+ 


Old  NODEN.HDL 

FN  INCW0RD3  = (word3:  minor)  ->  word3: 

IF  (VAL3  minor)  ==  7 
THEN  W0RD3  0 

ELSE  W0RD3  ( (VAL3  minor)  + 1) 

FI. 

New  NODEN-HDL 

FN  INCW0RD3  = (word3 : minor)  ->  word3: 

IF  minor  ==  7 THEN  0 ELSE  minor  + 1 FI . 


+ 
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Why  VIPER2? 


• Faster,  32  and  64  bit  multiply 


• Improved  interface  to  outside  world 


• New  design  methods  now  available 


+ 
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Extra  speed  by  .. 

• Instruction  pre-fetch 

• Dedicated  adders  for  P and  indexing 

• Half-cycle  overlaps  rather  than  full  cycle 

Speed  more  than  3x  at  same  clock  frequency 


Z'  > 
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On-board  Multiply  Instructions 


Three  separate  instructions,  F = 13,  14,  15 


• Signed,  32  bit  product,  stop  on  OVF 


• Unsigned,  LS  32  bits  of  product 


• Unsigned,  MS  32  bits  of  product 


+ 
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Improved  interface 


• ’’Call  on  signal"  instruction 


• "Frame  restart"  input 

• Longer  setup  and  hold  times  on 
memory  and  I/O  cycles 
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New  design  methods 

Top-down  synthesis  by  correctness-preserving 
transformations 

• Starts  from  specification  in  MIRANDA 

• Generates  proof  as  part  of  design  process 

• May  scale  up  better  than  post  hoc  proof 


+ 


1 


( 


+ 


+ 


VIPER  1A  perspective 


The  present  chip 
application  areas. 


falls  in  between 


the  main 


Automotive  and  comms:  too  expensive. 

tom  too  big  (5  memory  chips) 
minimum  system  too  ogv 


# Avionics*. 


not  fast  enough,  no  multiply 


• Space. 


about  right,  tiny  market 
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Reporting 
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Mechanical  Proofs  of  Fault-tolerant  Clock 

Synchronization 


N.  Shankar 

Computer  Science  Laboratory 
SRI  International 


Overview 


Introduction  to  clock  synchronization  protocols? 

A schematic  formulation  of  clock 
synchronization  (Schneider). 

The  Interactive  Convergence  Algorithm 
( Lamport/ Melliar-Smith). 

Verification  of  Schneider’s  formulation 
(Shankar). 

Verification  of  Interactive  Convergence 
(Rushby/von  Henke). 

A hardware-oriented  clock  synchronization 
protocol  (Infis/Moore). 

Verification  of  Infis/Moore’s  protocol 
(Rushby/Shankar). 

The  EHDM  Specification/Verification 
Environment. 

Conclusions. 
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Main  Observations 


• Fault-tolerant  clock  synchronization  is  a 
critical  component  of  a real-time  control 
system. 

• Proofs  of  the  correctness  of  clock 
synchronization  are  complex  and  subtle. 

• Informal  proofs  tend  to  be  tenuous  in  these 
domains. 

• Formal  verification  is  a useful  way  to  reduce 
errors  and  achieve  reliable  designs. 

• Specification/ Verification  could  contribute  to 
the  scientific  foundations  of  reliable 
engineering. 
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Fault-tolerant  systems 


• Critical  real-time  control  systems  such  as 
“fly-by-wire”  digital  avionics. 

• Replicated  processors  are  used  to  provide 
hardware  fault-tolerance. 

• Results  are  periodically  voted. 

• Clocks  must  be  synchronized  to  ensure 
approximately  synchronous  behaviour  across 
nonfaulty  processors. 
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Clock  Synchronization 


• Clocks  start  synchronized. 

• Over  time,  the  clocks  drift  apart. 

• The  clocks  are  periodically  synchronized  by 

o an  exchange  of  clock  values 

o computation  of  a mutually  agreeable 
clock  value 

o adjustment  of  the  logical  clock 
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Byzantine  Clocks 


Three  clocks  A,  B,  C. 

Suppose  clocks  drift  away  from  real  time  by  upto 
a minute  an  hour. 

C is  faulty. 

Clocks  resynchronize  around  noon  and  exchange 
clock  values. 

A reads  12  : 00  and  B reads  11  : 59 

A transmits  12  : 00  to  B and  C. 

B transmits  11  : 59  to  A and  C. 

C maliciously  transmits  12  : 01  to  A;  11  : 58  to 
B. 


c 
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Byzantine  Clocks 


Three  clocks  A,  D , C. 

Clocks  drift  from  real  time  by  upto  a minute  an 
hour. 

C is  faulty. 

Clocks  resynchronize  around  noon  and  exchange 
clock  values. 

A reads  12  : 00  and  B reads  11  : 59 

A resets  its  clock  to  the  mean  of  the  acceptable 
clock  values,  i.e.,  12  : 00. 

B similarly  resets  itself  to  11  : 59. 

A and  B are  not  any  closer  following 
resynchronization. 
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Clock  Generalities 


No  global  clocks  — single  point  of  failure, 
therefore  not  fault-tolerant. 

Synchronization  is  with  respect  to  other  clocks, 
not  real  time,  though  such  protocols  do  exist. 

Clocks  drift  at  rate  p with  respect  to  real  time. 

Period  of  drift  R between  resynchronization 
rou  nds. 

f.  bounds  the  error  in  reading  clock  values. 

To  keep  clocks  synchronized  to  within  8,  clocks 
should  be  within  8S  following  resynchronization, 
and 


8 > 8S  + 2 pR 

Each  clock  uses  the  same  convergence  function 
to  synchronize  to  within  8S, 
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Typical  numbers  (from  Rushby/von  Henke) 


Parameter 

Value 

Expl a nation 

N 

6 

No.  of  Clocks 

1 V 

R 

104.8  msec. 

Period 

j.  t- 

<5n 

132  nsec. 

Initial  skew 

6 

66.1  /xsec. 

Reading  error 

n 

15  x 10-6 

Drift  rate 

H 

6 

271  /itsec.  (F  = 1) 

Maximum  skew 

Clock  Requirements 

• Rl:  At  any  instant,  two  nonfaulty  clock 
readings  should  be  no  further  than  <5  apart. 

• R2:  There  should  be  a small  bound  on  the 
adjustment  needed  to  resynchronize  a clock. 
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Schneider's  Schema 


A generalization  of  various  protocols  consisting 
of: 


• Assumptions  on  the  behavior  of  nonfaulty 
physical  clocks. 

• Constraints  on  the  computation  of  nonfaulty 
logical  clocks. 

These  assumptions  and  constraints  are  used  to 
derive  a bound  on  the  skew  between  two 
nonfaulty  logical  clocks,  i.e. 

| LCp(t)  - LCq(t) | < 6 
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Physical  Clock  Assumptions 


N clocks  with  at  most  F faulty. 

t),  is  the  time  at  which  p resets  its  clock  for  the 
z'th  time. 


Interval  between  resets  is  bounded: 


rmin  ^ tp  ^ r max 


Skew  between  resets  is  bounded:  \Vp  -tU<  p 
Bounded  drift  rate  w.r.t.  real  time:  for  s > t 

(s  — 0(i  — p)  5:  Cp(s)  — Cp(0  < (s  — 0(1  "I-  p) 
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Logical  Clock  Assumptions 

A Convergence  function  Cfn  is  used  to  compute 
the  adjusted  logical  clock. 

Let  ©*,(g)  be  P's  reading  (estimate)  of  g s logical 
clock  at  time  t)r 

Then  LCP(t*p)  = Cfn(p,&p) 

The  i’th  adjustment  to  be  applied  to  the 
physical  clock  to  derive  the  logical  clock  is 

Adfp  = Cfn(p,  Op)  - Cp(tp) 

In  general  the  logical  clock  is  defined  to  be 

LCp(t ) = Cp(t)  + AdfP 
for  ilv  < t < fp+1 

€ pounds  error  with  which  clocks  are  read. 

Additionally,  certain  assumptions  on  behavior  of 
a satisfactory  convergence  function. 


Translation  Invariance 

Adding  X to  each  clock  reading,  adds  X to  the 
value  of  the  convergence  function. 

For  any  X and  0 mapping  clock  numbers  to 
clock  readings 

CMp,  (A q \Q(q)  + X))  = Cfn(p , 6)  + X 

Translation  invariance  is  used  to  compare  the 
values  of  convergence  functions  at  tlp  and  tlq. 


16 


Precision  Enhancement 

Formalizes  the  intuition  that 

• the  closer  the  good  clocks  are  to  each  other 

• the  closer  the  different  readings  of  the  same 
good  clock 

• then  the  closer  the  resulting  convergence 
function  values 
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Precision  Enhancement  (contd.) 

Given  any  predicate  P on  clocks  0 to  N — 1 that 
holds  of  at  least  N - F clocks. 

Given  p,  q , such  that  P(p)  and  P(q). 

Given  0V  and  0q  such  that 

• If  P(Z)  and  P(m),  then  1 0p(l)  - 0p(m)\  < Y 

• If  P(0  and  P(m),  then  1 6q(l)  - 6q{m) \ < Y 

• If  P(l),  then  \0p(l)  - 0q(l) | < X 

Then  there  exists  a bound  ir(X,Y)  such  that 
I Cfn(p,  0P)  - Cfn(q , 0q)\  < tt(X,  T) 

Illustrative  example  to  follow. 
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Accuracy  Preservation 


Bounds  the  adjustment  away  from  a good  clock 
reading. 

Given  any  predicate  P on  clocks  0 to  TV  - 1 that 
holds  of  at  least  N - F clocks. 

Given  that  P holds  of  p and  q. 

Given  0V  such  that  whenever  P(l)  and  P(m)  for 
any  two  clocks  l and  m,  then 

1 0P(l)  - 0P(m)\  < Z 


Then 

\Cfn(p,6p)  - 9p(q)\  < a(Z ) 

That  is,  if  the  good  clock  readings  are  within  Z, 
the  adjustment  away  from  a good  clock  reading 
is  no  more  than  a (Z). 
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The  Final  Result:  Agreement 


Al.  P S rmin 

Synchronization  rounds  are  distinct 


A2:  50  < 8S 

Initial  skew  no  greater  than  skew 
immediately  following  synchronization. 

A3:  5 s T 2 ()l'rnax  ^ 5 

Drift  between  synchronization  rounds  is 
below  8. 

A4:  7r(2e  -f-  2/>/3 , 5s  T 2p(rm«.x  ~k  /?)  ~k  2c)  ft  5s 
Skew  between  just  synchronized  clocks  below 

5s. 

A5:  a(5.s  T 2 pi^Vrnax  T P')  ~k  2c)  4 5 

Skew  between  synchronized  and  yet  to  be 
synchronized  clocks  below  5. 


Conclusion: 


t > 0 

A correct (p,t) 

A correct(g,  t) 

=>  | LC(p,t)  — LC(q,t)\  < 
Skew  between  nonfaulty  logical  clocks 
bounded  by  6. 


Verification  of  Schneider’s  Schema  using 

EHDM 


Proof  consists  of: 

• 30  axioms  involving  multiplication,  division, 
and  clocks. 

• 12  definitions 

• 95  lemmas. 

Proof  took  about  two  man-months  using  EHDM. 

Machine  verification  takes  1000  to  3500  CPU 
secs  on  SUNs. 

Numerous  inaccuracies  in  Schneider's  original 
presentation  were  corrected. 

The  machine  proof  adds  enormous  clarity  to 
Schneider's  insightful,  but  imprecise  descriptions 
and  definitions. 

Instantiation  of  Schneider’s  schema  in  progress. 


Lamport/Melliar-Smith’s  Interactive 
Convergence  (ICA) 

3F  + 1 clocks  needed  to  tolerate  F Byzantine 
faults. 

p records  (relative  discrepancies  of)  other  clock 
values  when  its  clock  reads  iR 

"Ignores”  clock  readings  further  than  A away. 

Adjusts  its  clock  by  the  'egocentric'  mean  of  the 
acceptable  clock  differences. 
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Instantiating  Schneider’s  protocol  with  ICA 

Convergence  function: 

/MW).*) 

ZCG\p,  9)  *~l  = 0 /y/ 

where 

, _ { :i:  if  k - 0(p)|  < A 

jixp{x,  u)  — < otherwise 

Translation  Invariance:  Note  that 

© ii* 

: 0(i)  + t)(q)J  =j@(q}tyr  t 
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Precision  Enhancement  of  ICA 


Given  that  for  all  correct  l,  m 

* \@p(0  — #g(OI  < X 

• \0P(l ) - 0p(m)\  < Y 


\eq(i)-eq(m)\<Y 


We  have 


ica(p,0p ) — ica(q,0q)  \ 
FY+2F/S. 


< X + 

= 7T  (X,Y) 


N 


X is  negligible,  but  y « A,  so 

3FA 


7T 


(X,Y) 


N 


Since  A > S + e,  we  get  N > 3F  + 1 


24 


Accuracy  Preservation  of  ICA 

If  nonfaulty  clock  readings  are  Z apart,  then  F 
faulty  clocks  can  contribute  a further  skew  of 
FA/N  to  the  egocentric  mean. 


So 


a(Z)  < Z + 


F A 

N 
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Rushby/von  Henke’s  verification  of  ICA 

using  EHDM 

Around  1—2  man  month  effort 
20  modules 

1,550  lines  of  specification 
166  proofs 

1 hour  elapsed  to  prove  them  all  on  Sun  3/75-8 

Verification  revealed  several  minor  flaws  in  a five 
year  old  journal  proof. 
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Flaws  in  Lamport/Melliar-Smith 

Main  induction  incorrect  (bad  approximations) 

Proof  of  Lemma  4 incorrect  (bad 
approximations);  also  typographical  error  in 
statement 

Lemma  1 false  in  absence  of  additional 
constraints  in  A2 

Lemma  2 similarly,  also  typographical  error  in 
statement 

Lemma  3 similarly,  and  unnecessarily  general 

Missing  requirement  for  S2  in  Lemmas  1,  3,  4, 
and  (when  repaired)  2 
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Original  Constraints  on  parameters 


Cl: 

C2: 

C3:  H = A 
C4:  ~ 5 "l-  e 

C5:  5 ~ <50  + pR 


C6:  6 > 2(e  + pS)  + 


2mA 
n — m 


npR 
n — m 
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New  Constraints  on  parameters 


Cl:  R>  3S 


C2:  S > Z 
C3:  Z > A 
C4: 

C5:  fi>60  + pR 


C6: 

> 


2(e  + pS)  + 


2mA  | npR 
n — m n — m 


npY- 
n — m 


+ P A 
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Infis/Moore’s  economic  approach 

Tolerates  F < N/2  omission  failures  for  N clocks. 

At  clock  reading  iR,  p broadcasts  a pulse  on  its 
private  line. 

Say  p receives  and  validates  N — f pulses 

pulse  bounded  from  above  and  below 
by  a good  pulse. 

Ditto  for  (F  - / + l)'th  pulse. 

p starts  new  clock  at  earlier  of  pulse  N — F with 
delay  D,  or  pulse  F — f + 1 with  delay  2D. 

Skew  6S  ~ D,  and  6 ~ 2D. 

Verification  nearly  complete  using  EHDM. 
Elaborates  significantly  on  informal  proof. 


30 


Schemata  for  Infis/ Moore’s  protocol 


HJIuSES 


3 


Extract  from  Infis/Moore 


(a)  Tk  ^ T , because  the  T‘  are  a subset  of  the  T 
r"  < r because  at  least  one  of  the  times  T 
r T,"  mus.  "bV  a message  f, on,  . processor  «h,ch  ,, 

,,  r o n 1 1 frpp  (and  synchronised)  and  ls  ei 

r,1m«  'rlheme'ige  Ln  .he  las,  laolr-free  processor 

°r  lei"*  , ^ T _m  because  the  T„.m  is  validated  by  all 

fault-free  processors  and  must  be  included  in  the  T 

Id)  Tk  , «T,-,  because  the  7*  are  a subset  of  the  T,. 

From  these  inequalities  we  have  that 

min  {T„_,  + d,  T„_m}  < W < min  {T„_  + <*,  W 0) 

t*  < T for  all  fc  and  T‘ = T„_,  for  some 
Now  / ,-/+ 1 k Tk  < imply  that 

fc,  SO  the  validity  tests  T J-f+L  “Tor  T 

T _7_  <2d.  Therefore  T„_m  - im-,  < d or  '--t 

l~T_m<d( or  both), 
ir  t"  m_  j _ < d,  eqn.  1 reduces  to 

A l * n ” m n I 

T ^ W ^ min  {T„_m  + d,  Tn-g } 

implying  that  fV  has  a range  of  at  most  d _ 

.r  t _ T < d then,  using  also  that  Tn-g  *n-t 

II  1 g 1 n ~ m ’ 

2d,  eqn.  1 yields 

T -d<W^Tn.g 

ln-g 


n 9 

molvine  that  fV  has  a ranee  less  than  d. 


Verification  of  Infis/Moore’s  protocol 

Formalization  is  fairly  close  to  hardware 
realization. 

Main  induction  over  synchronization  rounds 
completed,  as  well  as  all  of  the  important 
lem  mas. 

Machine  proof  is  remarkably  involved  and 
complex. 

Proof  took  two  man-months  of  effort  and  covers 
about  70  dense  pages. 
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Common  Errors 


Ignoring  failures. 

Distinguishing  real  and  clock  time,  and  relative 
versus  absolute  measurements. 

Ignoring  small  but  significant  quantities. 

Proving  one  statement  but  using  another. 

Imprecise  definitions. 

Erroneous  algebraic  manipulations. 

Implicit  assumptions. 

Incorrect  assumptions. 
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Difficulties  in  verification 

Dealing  simultaneously  with  failures,  temporal 
ordering,  relative  measurements,  drift. 

Have  to  be  careful  not  to  assume  anything 
about  failed  clocks. 

“Circular  definitions”  need  to  be  avoided. 
E.g.,  A round  ends  when  various  events  have 

taken  place. 

Various  events  take  place  as  scheduled  if  the 
clock  is  correct  at  the  end  of  the  round. 

Mentally  retaining  all  the  relevant  facts  is 
difficult. 
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EHDM  specification/verification  system 

Based  on  a simply  typed  higher-order  logic  with 
subtyping. 

t 

Parametric  modules  used  to  structure 
specifications. 

Specifications  can  be  proved  to  implement  other 
specifications. 

Components  include  parser,  typechecker, 
theorem  prover,  Hoare  sentence  prover,  and 
MLS  tool. 

Theorem  prover  contains  powerful  decision 
procedures  for  integer  and  rational  inequalities. 

New  implementation  should  be  ready  by  end  of 
1990. 
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Concluding  Observations 

Reasoning  about  fault-tolerant  clock 
synchronization  is  extremely  difficult. 

Proofs  involve  heavy  use  of  inequalities,  algebraic 
manipulations,  finite  set  theory,  and  induction. 

Protocol  designers  themselves  feel  the  need  for 
mechanized  verification  tools. 

Benefits  of  such  tools  are: 

• Design  discipline 

• Efficient  location/correction  of  design  errors 

• Design  library  for  future  reuse 

• Standardized  language  for  communicating 
designs  and  proofs 

Specification  and  verification  technology  could 
contribute  effectively  to  the  foundations  of 
reliable  engineering. 
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A HOL  Theory  for  Voting 

Paul  S.  Miner  James  L.  Caldwell 
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Outline 


• Introduction 

• Proofs  Comparing  Majority  and  Plurality 

• Proofs  of  Simple  Reconfiguration  Strategies 

• Future  directions 
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Introduction 


• Central  to  fault-tolerant  computing  is  redundancy  mange- 
ment. 

• Common  to  proofs  of  fault-tolerance  is  a maximum  fault 
assumption. 

If  there  are  m or  fewer  faults  in  the  system,  then  . . . 

• Typically  a maximum  fault  assumption  is  rather  restric- 
tive. Usually,  this  is  necessary  to  avoid  assumptions  about 
the  behavior  of  faulty  channels. 

- For  Interactive  consistency,  in  order  to  tolerate  m 
faults,  3m  + 1 nodes  are  required. 

- For  a majority  vote,  2m  -f  1 channels  are  required. 


• A maximum  fault  assumption  is  useful  because  it  allows 
us  to  reason  about  fault  tolerance  in  the  presence  of  arbi- 
trarily malicious  fault  behavior.  However,  analysis  of  the 
architecture  may  establish  certain  scenarios  in  which  the 
assumption  may  be  weakened. 
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• Should  fault-tolerant  systems  incorporate  features  which 
attempt  to  recover  from  failure  combinations  which  exceed 
the  maximum  fault  assumption? 

• If  so,  what  is  the  proof  obligation? 


• At  the  very  least,  it  is  necessary  to  show  that  existing 
proofs  which  depend  upon  the  maximum  fault  assumption 
still  hold. 
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Hypothetical  Scenario 

Imagine  that  plurality  voting  circuit  has  been  developed  for  use 
in  a a four  channel  fault-tolerant  computing  system.  Suppose 
that  a designer  is  considering  using  this  circuit  in  a system 
which  depends  upon  a majority  vote  in  order  to  maintain  cor- 
rect system  state. 

Can  this  voting  circuit  be  used  in  this  system? 
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First  we  define  existence  predicates  for  majority  and  plural- 
ity as  follows: 


V B .majority_exists  B = FINITE  B A 3x.\B\  < 2\B\X 

VB. plurality  .exists  B = 3ar.Vx'.(x  ^ x')  D \B\X,  < \B\X 

Where  B is  a bagl  |i?|  represents  its  cardinality,  and  \B\X 
represents  the  count  of  x in  B. 


Essentially  a bag  is  a set  without  absorption,  [a,  a,  ft]  = [6,  a,  a],  but  [a,  6]  ^ [a,a,fc] 


From  these  we  define  the  following  functions: 

'iB. majority  B = €X.|5|<2|JB|a; 

V B .plurality  B = e x.Vx'.(x  ^ x')  D \B\X>  < \B\X 
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The  property  we  need  to  prove  is 
Vi? .majority. exists  B D ( majority  B — plurality  B ). 
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The  first  step  was  to  show  that 

M B .majority ^exists  B D plurality -exists  B 

For  this,  we  needed  to  prove  the  following  lemma: 

VB .FINITE  B D (Vx  y.(x  ± y)  D |J9|j,  < (|£|  - |J5|X)) 

From  this  lemma,  coupled  with  rewriting  the  right,  conjunct 
of  majority -exists  to 

3x.(\B\-\B\x)  < | B|„ 

and  then  using  transitivity  of  *<’  and  *<’  we  can  establish  the 
existence  of  plurality  from  the  existence  of  majority. 
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In  order  to  show  the  equivalence  between  majority  and  plu- 
rality we  needed  to  establish  uniqueness  from  existence  (i.e. 
if  it  exists  then  its  unique).  This  allowed  us  to  substitute  in 
one  side  of  the  equation  and  then  show  that  the  chosen  value 
satisfied  the  predicate  embedded  in  the  other.2 


JThanks  to  Brian  Graham  of  the  University  of  Calgary  for  submitting  his  methods  of 
dealing  with  the  HOL  choice  operator  (‘e  ’ or  *®’)  to  the  info-hol  mailing  list. 
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Once  this  was  done  we  looked  at  proving  some  other  simple 
facts  about  voting  which  may  be  useful  in  the  analysis  of  fault- 
tolerant  architectures.  Specifically,  we  proved  the  preservation 
of  majority  for  a few  common  reconfiguration  schemes. 

• Graceful  Degradation 

• Perfect  Spares 

• Imperfect  Spares 

Of  course,  we  neglected  one  of  the  more  difficult  aspects  of 
reconfiguration,  namely  that  of  correctly  identifying  the  faulty 
channel.  All  that  we  have  done  is  prove  a little  bit  of  common 
sense. 
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Graceful  Degradation 

The  simplest  reconfiguration  strategy  is  graceful  degradation. 
This  consists  of  removing  a faulty  channel  and  continuing  pro- 
cessing with  one  less  channel  of  redundancy.  The  proof  for 
this  case  showed  that  a majority  is  preserved  if  a non-majority 
element  is  removed  from  consideration. 

First  we  show  existence 

VB.Vx.  majority  .exists  B D 

(x  e B)  D 

( x ^ majority  B ) D 
majority. exists  ( B — x) 

This  essentially  reduces  to  showing 

\B\  < 2\B\x.D  (\B\  - 1)  < 2\B\X, 

From  existence  we  get  uniqueness  so  we  can  then  show 

VB.Vz.  majority. exists  B D 

(x  e B)  D 

(x  ^ majority  B)  D 
( majority  B = majority  (B  — x)) 
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Perfect  Spares 

Sometimes,  in  addition  to  removing  a faulty  channel,  a good 
channel  is  added  to  the  configuration.  To  capture  this  scenario, 
we  showed  that  the  insertion  of  the  majority  element  to  a bag 
preserved  both  existence  and  value  of  the  majority. 

\/B.  majority^exists  B D 

majority-exists  (( majority  B)  0 B) 

VB.  majority-exists  B D 

( majority  (( majority  B)  © B)  = majority  B) 
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Imperfect  Spares 

Finally,  recognizing  that  it  is  possible  for  spares  to  fail,  it 
was  shown  that  the  removal  of  a non-majority  (e.g.failed)  el- 
ement, coupled  with  the  addition  of  an  arbitrary  clement  (of 
the  proper  type)  also  preserves  both  existence  and  the  value  of 
majority. 

VI? . majority  ^exists  B D 
Vx  x1 . (x  G B)  D 

(x  majority  B)  D 
majority-exists  (x1  © ( B — x)) 

\/B.  majority_exists  B D 
Vx  x' . (x  e B)  D 

(x  ^ majority  B)  D 

((majority  (x1  © (B  - x)))  = (majority  B )) 
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Future  Efforts 


• Establish  a base  for  reasoning  about  error  manifestations 
in  order  to  reason  about  Fault  Detection  and  Isolation. 

When  can  you  conclude  that  a redundant  channel  is 
faulty? 

• Explore  the  effects  that  incorporating  a plurality  voter 
would  have  on  the  OS  proofs. 

This  would  require  adding  assumptions  concerning  the 
behavior  of  faulty  channels. 

• Explore  possible  ways  to  incorporate  reconfiguration  strate- 
gies into  the  OS  effort. 

How  do  you  differentiate  between  a permanent  and  a 
transient  fault? 
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Formally  specifying  the  logic  of  an  automatic 

guidance  controller 


David  Guaspari 
Odyssey  Research  Associates 


Truth  arises  more  readily  from  error 
than  from  confusion. 

Francis  Bacon 
Novum  Organum 


The  Penelope  project: 


• Interactive,  incremental,  tool  for  formal 
verification  of  Ada  programs  (Larch/Ada 
specifications). 

— Structure  or  ordinary  text  editor 

— Permits  development  of  program  and 
proof  in  concert,  "reuse  by  replay” 


• Covers  large  subset  of  sequential  Ada. 


• Mathematically  based. 
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Problem:  specify  “logic1'  of  experimental  Au 
tomatic  Guidance  Control  System  for  a 737 


• Pilot  requests  kind  and  degrees  of  auto- 
matic assistance 

• Requests  may  be  honored,  disallowed,  “put 

on  hold 

• Responses  must  be  displayed 
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Work-in-progress:  Larch/Ada  specification 


• Formal  specification  of  Ada  code 

• Goals:  precise;  intelligible  to  designers  and 
implementors 


• Currently  wrong,  but  clear 
Related  work 


• Original  code  (CSC) 

• Experiment  in  redesign  (NASA) 
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Some  failures  of  informal  description 

1.  Ambiguous:  “Select”  a switch  vs.  “select” 
a mode. 

2.  Incomplete:  “CAS  ENG  may  be  engaged 
independent  of  all  other  AGCS  modes  except 
TIME  PATH." 

3.  Contradictory: 

• FPA  . . . cannot  be  deselected  directly. 


• [if]  ...  appropriate  selection  of  the  FPA 
SEL  . . . switch  returns  the  mode  to  the 
off  state  . . . 
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Larch/Ada  specifications:  "two-tiered” 

• Mathematical  part  (Larch  Shared  Language): 
defines  vocabulary 

• Interface  part  (Larch/Ada):  uses  vocabu- 
lary to  specify  code 
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Example:  specifying  executable  addition 

Mathematical  part:  defines  mathematical  + 
on  Int,  the  (infinite)  domain  of  mathematical 
integers 

Interface  part:  Specifying  evaluation  of  x+y 

• Type  integer  is  “based  on"  Int. 

• Return  value  (x  + y)  if 

min  < (x  + y)  < max. 

No  side  effects. 

• Otherwise,  raise  numeric_error.  No  side 
effects. 
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The  mathematical  part 


States:  AGCS_state,  Sensor_state,  etc. 
Actions: 

{alt_eng_switch,. . . ,alt_eng_knob(i),. . . , 

alt_capture,. . . } 

Modes: 

{alt_eng,fpa_sel,vert_path,. . . } 
Transition  operation: 

AGCS_state,  Action.  . » AGCS-State 
Observers:  active2d.  display,  ... 
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Building  mathematical  part  (the  AGCS  states) 

AgcsStructure  : trait 
AGCS_state  record  of 
(on:  Bool, 

modes:  Set_of_modes, 
engaged:  Engagement_status, 
setting:  Value_settings, 
window:  Window_array) 
includes  Set(Mode,Set_of_modes) 

introduces 

transition: 

AGCS-State,  Action,  Sensor_state, 
Flight_plan  — > AGCS_state 
initial_on_state:  — > AGCS_state 

asserts 
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Description  of  mode  changes  caused  by  switches 


• Is  the  mode  directly  deselectable? 

• What  mode  changes  result? 

• Under  what  conditions  is  the  mode  di- 
rectly selectable? 

• What  mode  changes  result? 
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Building  mathematical  part  (mode  changes) 

HorPathSwitch  : trait 

includes  SwitchShell{hor_path} 
asserts  for  all 

[agcsmodes:  Set_of_modes, 
pi:  Flight_plan, 
sens:  Sensor_state] 

hor_path_deselectable 
hor_path_selectable(agcsmodes,pl)  = 

(auto  6 agcsmodes)  a active2d(pl) 
hor_path_selection_result(agcsmodes,sens,pl) 
[hor_path]  u [cas]] 

hor_path_deselection_result(agcsmodes)  = 
[tka_sel]  u [cas]] 
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Intuitive  description  of  window  status  ( chosen 
vs.  current): 


• The  w_knob  makes  the  corresponding  w- 
window  chosen. 


• Any  action  selecting  the  w mode  makes 
the  ^-window  chosen. 


• Any  action  deselecting  the  w mode  makes 
the  ^-window  current. 


• Any  other  action  leaves  the  status  of  the 
^-window  unchanged. 
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Building  the  mathematical  part  (window  changes) 


StatusShell  : trait 

imports  AgcsStructure 
introduces 

#. component  : 

Window_array  — > Window-Status 

md:  — > ► Mode 
knob  : Value  -»  Action 
asserts  for  all  [agcs:AGCS_state,  • • -] 

abbreviation 

ages'  ==  transition(agcs, act, sensor, plan) 
ages’ .window. component  = 

if  md  € ages'. modes  - aegs. modes 
then  chosen 

elsif  md  € ages. mode  - ages’. modes 
then  current 

elsif  act  = knob(i)  then  chosen 
else  ages. window. component 

Example:  StatusShell{alt,alt_eng, Airspeed} 
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Design  of  the  code: 


• Packages  panel-logic,  display -manager, 
sensor.data,  flight_plan,  f light_control. 

• State  of  panel-logic  based  on  AGCS_state, 
etc. 

• Actions  procedures  of  panel-logic: 

— read  State  Of  panel-logic,  sensor-data, 
flight  _plan 

— modify  states  of  panel-logic, 
display-manager,  flight  .control 

• Consistent  with  polling,  interrupts,  etc. 
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Specifying  the  code: 

WITH  TRAIT  AgcsLogic , AgcsProperties , 

I LogicalDisplay 

i with  sensor.dat a,  fligM-P^an, 

. display .manager , f light .contro 


a tvnes-  use  sensor .data.types , 

with  sensor .data.types, 

package  panel.logic 

| BASED  ON  AGCS.state 

— I invariant 

panel-logic . on  ->  goodCpa»cl-log«> 

__i  INITIALLY  not  panel.logic- on 


end  panel.logic; 
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procedure  att_cws_switch; 

— | WHERE 

— | GLOBALS  IN  panel.logic 

— | GLOBALS  OUT  di  splay  .manager , 

— | f light. control , 

— | panel.logic 

— | IN  panel.logic. on 

— | OUT  panel.logic  = 

— | transition(IN  panel.logic, 

— | att.cws.switch, * , *) 

— | OUT  FORALL  ss:  Sensor.state : : 

— | look (display .manager ,ss)  = 

— | display (panel. logic, ss) 

— I OUT  FORALL  md:mode  :: 

— | fc .engaged (md, flight .control) 

— | engaged (md, panel.logic) 

— | END  WHERE; 


17 


procedure  turn_on_agcs 

— I WHERE 

• • • 

— I OUT  panel_logic  = initial_on_state 

« • # 

— I END  WHERE; 
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Verification  of  Floating-Point  Software 

D.  N.  Iloovcr 

Odyssey  Research  Associates,  Ithaca  NY 


Abstract 

Floating  point  computation  presents  a number  of  problems  for  for- 
mal verification.  Should  one  treat  the  actual  details  of  floating  point 
operations,  or  accept  them  as  imprecisely  defined?  or  should  one 
ignore  round-off  error  altogether,  and  behave  as  if  floating  point  op- 
erations are  perfectly  accurate?  There  is  the  further  problem  that  a 
numerical  algorithm  usually  only  approximately  computes  some  math- 
ematical function,  and  we  often  do  not  know  just  how  good  the  ap- 
proximation is,  even  in  the  absence  of  round-off  error. 

ORA  has  developed  a theory  of  asymptotic  correctness  which  al- 
lows one  to  verify  floating  point  software  with  a minimum  entangle- 
ment in  these  problems.  We  describe  this  theory  and  its  implemen- 
tation in  the  Ariel  C verification  system,  also  developed  at  ORA.  We 
illustrate  the  theory  using  a simple  program  which  finds  a zero  of  a 
given  function  by  bisection. 
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Difficulties 


• Machine  real  arithmetic  does  not  have  nice 
mathematical  properties 

• Doesn’t  match  ideal  arithmetic  (overflow,  round- 
off, underflow) 

• Programs  don’t  satisfy  the  specification  we’d 
like  them  to 
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Asymptotic  Correctness 

• Specify  “ideal  behavior”  of  the  program  (e.g. 
“program  computes  the  square  root  of  its  in- 
put”) 

• Verify  that  if  program  is  run  on  a sequence  of 
machines  converging  to  perfect  accuracy,  then 
program’s  behavior  converges  to  ideal  behav- 
ior 
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Advantages  of  the  Asymptotic  Approach 

• Machine  real  arithmetic  can  be  specified  loosely 

• Specifications  can  be  written  in  terms  of  ideal 
behavior 

• Verification  does  not  require  roundoff  error  anal- 
ysis 

• Verifies  logical  correctness  — absence  of  “bugs” 
from  inaccuracy  of  machine  arithmetic  that 
are  not  related  to  error  magnitude. 
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Nonstandard  analysis 


RC  *K 

Standard  part  map 

St  : *R  — R 

rounds  off  a finite  nonstandard  real  to  an  infinitely  close  stan- 
dard real. 


Continuity 

/ is  continuous  at  («i, . . . , «„)  if 

st{f(d\,.  . . ,«„))  = . . • ,st(an)) 

Differentiation  by  algebraic  manipulation 

Let  st(e ) = 0,  e ^ 0.  For  all  standard  x , 


d(x2) 

dx 


f(x  + e)2-x2 

st  ^ — - — 
2ear  + £2  j 

2x  -f-  c) 


= 2x 


Nonstandard  Analysis 

• Asymptotic  approach  can  be  formalized  natu- 
rally in  nonstandard  analysis  using  infinitesi- 
mals 

• Primitive  operations  are  assumed  to  return 
values  which  are  infinitely  close  to  the  ideal 
values  when  the  arguments  and  ideal  answers 
are  finite 

• Programs  are  specified  to  have  behaviors  in- 
finitely close  to  ideal  behavior  when  inputs  are 
finite 
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Finding  Roots  of  a Continuous  Function 

• find_zero  seaxchs  for  a root  of  a user-supplied 
function  F by  bisection. 

• At  each  iteration,  it  tests  to  see  if  the  values 
of  F at  the  left  endpoint  and  the  midpoint 
are  of  opposite  sign,  and  changes  one  of  the 
endpoints  to  the  midpoint  so  as  to  keep  a root 
between  the  two  endpoints. 

• The  program  terminates  when  it  finds  a root 
or  when  it  reachs  a user-supplied  bound  on 
the  number  of  iterations. 
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float  f ind_zero (lef tO , rightO .maxit ) 
float  lef tO, rightO; 
int  maxit; 

{ 

float  left .right, center; 
float  cval.lvalO.rvalO; 
int  numit; 

numit  = 0; 

lvalO  = F(leftO) ; 
rvalO  = F(rightO); 

left  - leftO; 

right  ■ rightO; 

center  * (left  + right)/2.0; 

cval  = F(center); 

while (cval  !=  0.0  &&  numit  < maxit)  { 
if  (lvalO  * cval  < 0) 
right  = center; 

else 

left  = center; 

center  = (left  + right )/2.0; 
cval  = F(center); 
lvalO  = F(left) ; 
numit  * numit  + 1 ; 

> 

return (center) ; 

> 


Odyssey  Research  Associates,  Inc, 


Specification  of  find_zero 

IF  F is  continuous  and  find_zero  is  started  up 
with 

• leftO  and  rightO  not  “large”; 

• max  it  “large” ; 

• F(lef  tO)  and  F(rightO)  of  opposite  sign 

THEN  f ind_zero  terminates  normally  (i.e.  with- 
out an  exception)  and  the  value  output  is  “close 
to”  some  zero  of  F. 
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Attempted  Verification 

• Proof  of  termination  is  easy. 

• Proof  that  termination  is  normal  is  a bit  harder. 
Must  prove  that  no  overflow  happens.  To  prove 
this,  must  prove  that  the  values  of  the  end- 
points stay  in  some  range  of  numbers  which 
are  not  “large”. 
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How  would  we  prove  that  the  program  returns  an 
approximation  to  a root? 

• Prove  when  the  program  terminates,  the  end- 
points are  “close” . This  follows  from  the  fact 
that  the  program  halves  the  interval  a “large” 
number  of  times. 

• Prove  there’s  always  a root  between  the  end- 
points. This  should  follow  from  the  way  the 
program  decides  whether  to  move  the  left  end- 
point or  the  right.  From  this  we’d  get  center 
“close  to”  a root. 

Unfortunately,  it’s  not  true  that  there’s  always 
a root  between  the  endpoints. 
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The  Bug 

• In  the  test  statement,  can  have  lvalO  and 
cval  of  opposite  sign,  but  have  the  product 
underflow  to  0.  This  causes  the  program  to 
move  the  wrong  endpoint. 

• Tests  bear  out  this  bug. 
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Possible  Fixes 

Several  ways  to  fix  this  bug 
• Change  test  to 

ClvalO  < 0 til  cval  >=  0>  1 1 
(lvalO  >■  0 tik  cval  < 0) 


Cange  teat  so  Instead  of  ^"1 

St.Targ«  vine  of  F against  the 

This  doesn’t  necessarily  keep  a root  between 
^ endpoints,  bnt  it  delivers  an  approx, ma- 

tion  to  a root  anyway. 
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Ariel 


• Verification  system  for  subset  of  C including 
real  arithmetic  and  some  UNIX  system  calls. 

• Implements  nonstandard  formalization  of  the 
asymptotic  approach. 
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Semantic  Verification 

Ariel  verifies  programs  by  generating  a <lc 
scription  of  the  program’s  denotation  in  a ng  »ei- 
order  language  (the  Clio  metalanguage) 

, Specifications  are  statements  about  the  deno 
tation  in  the  Clio  metalanguage 

, Verification  is  a proof  of  the 
rectly  from  the  description  of  the  deno 

in  Clio  theorem  prover 

. Specifications  can  bo  any  statement  about  the 
program’s  denotation  which  can  be  expressed 
in  the  Clio,  including  termination 
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C Semantics 


• A “run”  of  the  program  is  modeled  as  a se- 
quence of  events 

• Events  are: 

— the  event  of  going  into  a certain  state 

— terminating  and  returning  a value 

— terminating  and  returning  no  value 

— raising  an  exception 

— an  “unknown”  event 

• The  semantics  of  the  program  is  expressed  as  a 
collection  of  axioms  saying  which  sequences  of 
events  can  happen  in  the  course  of  executing 
the  program. 
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Sample  Verifications 

• ZBRENT  — a program  which  finds  zeros  of  a 
continuous  function  by  bisection 

• SWAP  — a very  simple  program  to  swap  the 
contents  of  2 locations  which  contains  a sur- 
prising bug 

• HOSTILE  BOOSTER  — a suite  of  programs, 
developed  by  Applied  Technology  Associates 
for  SDIO,  that  estimate  hostile  booster  trajec- 
tories. This  verification  is  currently  in  progress. 

• SECURE  DEVICE  DRIVER  — specification 
and  verification  of  security  for  an  Ethernet  de- 
vice driver.  Currently  in  progress. 
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Abstract 

1 his  talk  reports  the  results  of  a NASA  SBIR  project  in  which 
we  developed  CSP- A riel,  a verification  system  for  C programs  which 
use  Unix  system  calls  for  concurrent  programming,  interprocess  com- 
munication, and  file  input  and  output.  This  project  builds  on  OIl  A’s 
Ariel  C verification  system  by  using  the  system  of  Hoare’s  book  Com- 
municating Sequential  Processes  to  model  concurrency  and  communi- 
cation. I he  system  runs  in  OR  A*s  Clio  theorem  proving  environment. 
We  outline  how  we  use  CSP  to  model  Unix  concurrency,  and  sketch 
the  CSP  semantics  of  a simple  concurrent  program.  We  discuss  plans 
for  further  development  of  CSP- A riel. 
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C Formal  Verification  with 

Unix  communication  and  concurrency 

(NASA  SBIR) 

Aim:  Verification  system  for 

• C programs 

• Unix  system  calls 

• concurrent  programming  (fork,  wait, 
exit,  pipe) 

• file  and  device  i/o  (read,  write,  open, 
close). 


Example  program. 


void  producer  (); 
voi d consumer ( ) ; 
int  pipedes  [2]  ; 

void  main  ( ) 

{ 

int  id; 

if  (pipe (pipedes ) ==  -1)  return; 

id  - fork() ; 
if  (id  =*«  -1)  return; 
if  (id  0)  consumer (); 

else  producer ()  ; 

return ; 

} 

void  producer  () 

( 

char  c; 
int  status; 

while  (read(0,  &c,  1)  !=  0)  /*  0 = standard  input  filedes  */ 

write (pipedes ( 1 ] , &c,  1)  ; 

close (pipedes ( 1 ] ) ; 
exit (wait (^status)  ) ; 

} 

void  consumer ( ) 

{ 

char  c; 

close (pipedes [ 1 ]) ; /*  so  that  pipe  read  will  fail  when  producer 

closes  its  write  end  of  pipe  */ 
while  ( read (pipedes [ 0 ] , &c,  1)  !=  0) 

write(l,  &c,  1);  /*  1 = standard  output  filedes  */ 

exit (0) ; 

} 


Example  Program  Schematic 


Technical  Approach 

• C semantics  via  Ariel  operational  semantics  (pre- 
existing) 

• Unix  communication  and  concurrency  semantics 
via  Hoare's  CSP 


2 


CSP  (Communicating  Sequential  Processes) 

• See  Hoare’s  book,  Communicating  Sequential  Pro- 
cesses. 

• An  algebraic  language  for  describing  systems  of 
processes  with  synchronous  communication. 

• Objects  of  the  language  are  processes  and  events. 

• Processes  resemble  state  machines,  events  the  in- 
put alphabet.  Deterministic  and  nondeterministic 
processes. 


• Processes  participate  in  events  and  are  transformed 
by  them. 

• Synchronous  communication  by  participation  in  shared 
events. 
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Unix  modeling 


• Unix  processes,  files,  pipes,  and  certain 
system  tables  are  modeled  as  determinis- 
tic CSP-processes. 


• Forking,  pipe  creation,  file  opening  and 
closing,  I/O,  waiting,  and  exiting  are  mod- 
eled as  events. 
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Example:  Asynchonous  pipe  communication 


Sending  process  A,  pipe  P,  receiving  process 
B. 


Processes  transformed  by  events 


Verification  method 


• C program  given 

• Ariel  front  end  generates  Caliban  expression  for 
abstract  syntax  tree  of  program. 

• Ariel  C semantics  plus  Unix  system  call  semantics 
define  denotation  of  a C program  and  associated 
files  inside  operating  system  as  a CSP  process. 

• Internal  operations  of  systems  of  processes  hidden 
by  CSP  concealment  operation. 

• We  reason  about  the  resulting  CSP  process  in 
Clio.  Main  tools  are  induction  on  traces  (event  se- 
quences) of  processes,  and  algebraic  laws  of  CSP. 
Clio  is  a very  general  theorem  prover,  and  we  are 
not  limited  in  the  kinds  of  properties  we  can  prove 
about  processes. 


Producer  as  a CSP  process 


Hiding  events: 


Overall  process  with  non-I/O  events  hidden. 
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CSP-Ariel  Development  Plan 


• C semantics  via  Ariel  symbolic  interpreter  (exist- 
ing) 

• Unix  communication  and  concurrency  semantics 
via  deterministic  CSP  (initial  work  completed). 

• Extensions  to  support  network  communication  planned 
(sockets). 

• Nondeterministic  CSP  and  event  concealment  for 
specification  and  modularity  (planned) 

• Graphic  specification  support  using  Romulus  inter- 
face (planned) 


Clio,  Caliban,  and,  Ariel 

• Ariel  is  a semantic  verification  system  for  a sub- 
set of  C written  in  Caliban  and  the  Clio  met- 
alanguage. Floating  point,  overflow  support  via 
asymptotic  correctness. 

• Caliban  is  a lazy,  purely  functional  language  based 
on  recursive  equations  and  pattern  matching. 

• Clio  is  a higher-order  logic  theorem  proven  Cal- 
iban is  its  term  definition  language.  Clio  s main 
proof  methods  are  induction  on  Caliban  defini- 
tions, term  rewriting,  and  case  splitting. 
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